HTTP 429
The server reported that this request was rate limited. Pulse records the first observed 429 and can stop dispatching further requests. Requests already in flight may finish or be cancelled.
FREE BROWSER TOOL / RATE LIMITS
Test API rate limits and understand HTTP 429.
Run a controlled series of requests from your browser. Pulse counts 429 responses, reads rate-limit headers your API exposes, and turns the run into a clear, shareable summary.
Published October 27, 2026 · Updated October 28, 2026 · Pulse
Open the rate-limit analyzer →Only test endpoints you own or are authorized to test. Free runs are capped at 1,000 requests and 10 concurrent workers.
How to run a useful test
- Choose a safe endpoint. Use a GET endpoint you control. A health or read-only API route is better than a route that creates or deletes data.
- Use guided setup. Pulse selects 100 requests, one worker, a 100 ms delay, and automatic stop on the first observed 429. Review the target URL before starting.
- Read the evidence. Look for the first 429, the count of successful responses, and any readable quota or retry headers. Increase the workload only when your testing policy allows it.
- Share the summary. The analyzer's safe JSON export and share link contain aggregate numbers only. The existing raw CSV and JSON exports contain endpoint and response details, so treat those as sensitive.
What the signals mean
Retry-After
When the API exposes this header, it can indicate a wait time in seconds or an HTTP date. Pulse shows the observed delay; it does not schedule a retry for you.
Limit and remaining
Some APIs expose a quota and remaining allowance. Header names and windows vary by API. A visible quota is evidence about that API's policy, not proof of a universal requests-per-second threshold.
No visible limit
If no 429 appears, the test did not hit an observable limit. It does not mean the endpoint is unlimited. If requests fail at the network layer, CORS, connectivity, and server errors may look alike in the browser.
What a browser test can tell you
Pulse sends requests directly from your device, so latency and throughput depend on your network and browser. Browsers can read cross-origin response details only when the target allows it through CORS. Pulse reports the successful response rate observed before the first 429, when measurable, but that rate is not a guaranteed safe operating limit. A production limit should be verified against the API provider's policy and with controlled tests over time.
For an API you maintain, expose the rate-limit headers you want browser clients to read using Access-Control-Expose-Headers. If you do not control the API, a server-side test may be necessary to inspect its response details.
Ready to inspect an endpoint?
Start with the guided settings, then review the 429 and header evidence in the analyzer.
Start a free rate-limit test →