⏱️Dev

Retry-After Header Parser (HTTP 429 and 503)

Paste a Retry-After value in delay seconds or HTTP-date form to get the wait in seconds and minutes, or the exact instant to try again.

Retry-After

Wait

—

How long to wait after a 429 or a 503

Retry-After is the header a server uses to say when it is worth trying again. It shows up alongside 429, when you have blown through a rate limit, alongside 503, when a service is temporarily down, and alongside 301/302 in some maintenance scenarios. What confuses people is that it accepts two completely different formats in the same field.

It may arrive as a bare number, and then it means seconds from now — "Retry-After: 120" means two minutes from now. Or it may arrive as a full HTTP date, in the style of "Wed, 21 Oct 2026 07:28:00 GMT", which is an absolute instant. Paste either one and the page translates it: the number is also expressed in minutes, and the date turns into how many seconds remain from this moment.

On the client side, honouring that value is what separates a polite retry from one that makes things worse. If the server asked for 120 seconds, retrying every 5 only lengthens the queue. And when the header is absent, the sensible default is exponential backoff with jitter — a delay that grows with each failure, plus a random spread so that every client does not come back at the same instant.

Frequently asked questions

Can the date value be in the past?

It can happen, either from a skewed clock or because the response sat in a cache. The page shows the negative difference rather than hiding the case. Safe client handling is to treat it as zero and apply your own backoff, never to retry immediately in a loop.

Must I send Retry-After on every 429?

The specification does not require it, but it helps whoever consumes your API a great deal — without it, the client has to guess. If your limit uses a fixed window, the natural value is the time left until the window rolls over.

What does the browser do with this header on its own?

During normal navigation, almost nothing: it will not repeat the request because of it. The one reading Retry-After is your code — the fetch call, the backend HTTP client, the worker draining a queue. On a 503 with a short Retry-After, some crawlers and proxies do honour the value.

Related Tools

🗜️

Accept-Encoding Header Parser

Splits an HTTP request header such as gzip, deflate, br;q=1.0 into codings ranked by q value, assuming q=1 whenever the parameter is missing.

🔤

Accept-Charset Header Parser

Breaks an Accept-Charset header into charsets and q-values and ranks them by preference. The header is deprecated; today's clients simply assume UTF-8.

📡

HTTP Status Code Lookup

Type any HTTP status code from 100 to 511 and read its official reason phrase, across the informational, success, redirect, client and server error ranges.

📡

HTTP Status Codes

Look up all HTTP status codes with names and descriptions. Search by code or keyword. Quick reference for developers.

💾

Cache-Control Parser

Read a Cache-Control header and show each directive (max-age, no-cache, public, immutable, stale-while-revalidate) with explanation.

📡

HAR Viewer

Read pasted HAR (HTTP Archive) and list requests with method, status, URL and time.