Retry-After and Backoff

Retry-After is an HTTP response field specifying how long the client ought to wait before a follow-up request. RFC 9110 defines the value as “either an HTTP-date or a number of seconds to delay after receiving the response,” where a delay is “a non-negative decimal integer.” So Retry-After: 20 asks for a twenty-second delay and Retry-After: Thu, 17 Sep 2026 18:00:00 GMT asks for a wait until a moment — and a client that parses only one of the two forms will mishandle servers that send the other.

What the field means depends on the response it rides on. The specification distinguishes two cases: with a 503 (Service Unavailable) it “indicates how long the service is expected to be unavailable to the client,” and with any 3xx (Redirection) it “indicates the minimum time that the user agent is asked to wait before issuing the redirected request.” In practice it is also widely sent with 429 (Too Many Requests). None of these promise that the next request will succeed; the field is an instruction about when to try, not a reservation. A server that sends it is usually throttling — the field is how a cap becomes something the client can honor rather than fight.

Backoff increases or otherwise spaces retry delays, while jitter randomizes them to reduce synchronized retries. The two sources of a delay have to be combined deliberately, because they answer different questions. A Retry-After value is what the server knows — the window it expects to need, or the reset moment of a rate limit. A computed backoff is what the client guesses when the server says nothing. When both are present, the server’s value is a floor: take the larger of the two, and if the policy adds jitter, add it after the floor rather than around it, so the random choice can never shorten the requested wait. When the required wait exceeds the job’s remaining budget, stop and reschedule rather than retrying early. Ignoring the field and retrying immediately is how a cap turns into amplification, and how a struggling dependency ends in a cascading failure.

Limit attempts and elapsed time separately. Retry only selected failures and safe operations: a timeout after a write can leave its effect committed — the partial failure the client cannot distinguish, which is why the durable fix is an idempotent operation rather than a cleverer retry policy. An authentication failure needs its documented recovery flow, not repeated blind requests. For how a collector applies bounded retries to partner APIs and files, see Collecting Data from APIs, Files, and Object Storage.

References:

• HTTP Retry-After (RFC 9110)