Retry-After & Rate Limit Tester
Read 429 and 503 headers, test your client against a real rate limiter, and copy retry code with exponential backoff
Read the headers
No rate limit headers found.
Test against a real limiter
A working endpoint for your own client: it allows the requests below per window, per visitor, then refuses with Retry-After until the window ends.
https://toolninja.io/api/mock/rate-limit?limit=3&window=15Backoff for when there's no Retry-After
0 ms–1 seconds → 0 ms–2 seconds → 0 ms–4 seconds → 0 ms–8 seconds → 0 ms–16 secondsAt most 31 seconds of waiting in total.
// Retries 429 and 503, waiting as long as Retry-After says, or backing off when it's absent.
// Only retry requests that are safe to repeat: a POST may need an idempotency key.
function retryAfterSeconds(value) {
if (!value) return null;
if (/^\d+$/.test(value.trim())) return Number(value);
const date = Date.parse(value);
return Number.isNaN(date) ? null : Math.max(0, (date - Date.now()) / 1000);
}
async function fetchWithRetry(url, options = {}, maxRetries = 5) {
for (let attempt = 0; ; attempt++) {
const response = await fetch(url, options);
if ((response.status !== 429 && response.status !== 503) || attempt >= maxRetries) return response;
const delay = Math.min(60, 1 * 2 ** attempt);
const wait = retryAfterSeconds(response.headers.get("retry-after")) ?? Math.random() * delay;
await response.body?.cancel();
await new Promise((resolve) => setTimeout(resolve, wait * 1000));
}
}
Pasted headers stay in your browser. The test endpoint keeps only an anonymous counter that expires with the window. To see which status codes are worth retrying, check HTTP Status Codes.
Was the Retry-After & Rate Limit Tester helpful?
About this tool
The Retry-After & Rate Limit Tester helps you handle HTTP 429 and 503 responses correctly. Paste response headers and it explains each one and tells you how long a client should wait: Retry-After in seconds or as a date, Retry-After-Ms, the RateLimit headers from the IETF draft, the X-RateLimit family, and provider variations such as OpenAI's durations (6m0s), GitHub's Unix timestamps and Anthropic's dates. Then test your code against a real limiter. Choose how many requests to allow per window, and the endpoint counts your requests and returns 429 or 503 with a correct Retry-After once you're over, then works again when the window ends. Point your own client at it, or run the test on the page to watch a well-behaved client wait and recover. For when there's no Retry-After, a backoff calculator shows each retry's delay range and writes retry code in JavaScript and Python, with jitter, a delay cap and proper handling of both Retry-After forms.
When to use it
- →Testing that your API client waits and retries after a 429
- →Working out what a confusing set of rate limit headers means
- →Checking whether a reset value is a delay or a timestamp
- →Choosing backoff settings and copying working retry code
Tips
- ◆Always read Retry-After as either form: a whole number of seconds or an HTTP date. Code that assumes seconds breaks on the date form.
- ◆Add jitter. Clients that fail together and retry on the same schedule hit the server together again.
- ◆Only retry requests that are safe to repeat. A POST that creates something may need an idempotency key.
- ◆Set a limit on retries and on total time, so a long outage can't pile up waiting requests.
- ◆curl has this built in: --retry honors Retry-After from version 7.66.
Frequently asked questions
What is the Retry-After header?
A response header saying how long to wait before trying again, sent with 429, 503 and sometimes 3xx responses. RFC 9110 allows two forms: a whole number of seconds (Retry-After: 120) or an HTTP date (Retry-After: Wed, 21 Oct 2026 07:28:00 GMT).
What's the difference between Retry-After and X-RateLimit-Reset?
Retry-After is standard and tells you directly how long to wait. X-RateLimit-Reset is a convention that varies: some APIs send seconds from now, others a Unix timestamp. If both are present, follow Retry-After.
Should I retry on every error?
No. Retry 429 and 503, and usually 502, 504 and network errors on requests that are safe to repeat. Don't retry other 4xx errors, because the same request will fail the same way.
How does the test endpoint work?
/api/mock/rate-limit takes limit, window, status and format. It counts requests per visitor in fixed windows, using an anonymous counter that expires with the window. There's also an overall limit of 300 requests per 10 minutes. It allows cross-origin requests, so you can call it from code running on localhost.
ToolNinja