API Load Tester & Response Time Monitor

Before you reach for a real load-testing rig the question is usually smaller. Does this endpoint respond consistently, and how slow is its worst request? The API Load Tester fires a sequence of requests from your own browser, times every one of them, and reports the spread rather than the average, because the average is precisely the figure that hides whatever you were trying to find out.

Requests go out at a fixed interval rather than all at once. That makes this a latency probe and not a concurrency test, a distinction worth holding on to, since a browser tab will never saturate a server and numbers that pretend otherwise are worse than no numbers at all.

A single test request runs first by default, so a typo in the URL costs you 1 request instead of 500. Responses are then banded by time. Fast is under 300 ms, Good under 800, Slow under 2,000, and anything past that is Very Slow, with failures counted apart from all four.

Running a Latency Probe

1. Enter the URL and pick a method. All 7 are available, from GET through PATCH to OPTIONS.
2. Add headers as JSON if the endpoint needs authentication, and a body for the methods that take one. Bodies are capped at 100,000 characters.
3. Set the interval and the request count. The interval runs from 50 ms to 60 seconds and the total is capped at 500 requests.
4. Leave the single test request enabled. It validates the whole configuration and shows you one full response before the batch starts.
5. Watch the rows arrive and stop the run at any time. Partial results are kept rather than discarded, so an early stop still gives you the percentile figures for what completed.

Accuracy and What a Browser Cannot Measure

• Every timing includes DNS resolution, TLS negotiation and the full network round trip. It is what a user experiences, not what the server logs, and the two can differ by hundreds of milliseconds.
• The 95th percentile is the number worth reading. An average hides the occasional 3-second response that is what your users will actually complain about.
• Cross-origin requests are subject to the browser's own rules. An endpoint without permissive CORS headers fails here while working perfectly from a server, and that failure is about the browser rather than about the endpoint.
• Requests time out after 20 seconds and are counted as failures. A genuinely slower endpoint cannot be measured from this page.
• Sequential requests at a fixed interval measure latency under no load. Real concurrency needs a tool that can open many connections at once, which a browser tab deliberately cannot.
• Caching will flatter you. A repeated GET may be served from the browser cache and report an implausibly fast time, so vary the URL or send a cache-busting header when that matters.