A downstream HTTP service returns a 429 Too Many Requests response with a Retry-After: 30 header. How should a well-behaved client's retry logic use this header, and what should it do if the header is absent on a 429 or 503 response?

## What the header adds to blind retry logic Most retry logic operates blind: the client has no information from the server about why a request failed or how long a wait is likely to help, so it falls back to a generic policy — exponential backoff with jitter — calibrated to be reasonable across many possible causes of failure. The `Retry-After` HTTP response header, defined for responses like `429 Too Many Requests` and `503 Service Unavailable`, changes this by letting the server communicate an explicit, situation-specific recovery estimate directly to the client. - **For a 429** (rate limiting), the value usually reflects when the client's rate-limit window resets — the server knows exactly when it will start accepting requests from this client again, and it's telling the client rather than making it guess. - **For a 503** (service temporarily unavailable, e.g., during a deployment or planned maintenance window), the value reflects the server's own estimate of when it expects to be healthy again. The header's value can be expressed in one of two formats: an integer number of seconds to wait (`Retry-After: 30`), or an absolute HTTP-date (`Retry-After: Wed, 21 Oct 2026 07:28:00 GMT`) — a client parsing this header needs to handle both, since different servers and different response codes use each format. ## Treat the server's value as authoritative The correct client behavior is to treat the header as an authoritative lower bound on the wait time and honor it rather than override it with the client's own shorter backoff schedule. Retrying sooner than instructed doesn't just risk another 429/503 — for rate-limited APIs, some providers explicitly penalize clients that repeatedly ignore Retry-After by extending the rate-limit window or applying stricter throttling, effectively treating early retries as a signal of a non-compliant client. This makes Retry-After meaningfully different from ordinary exponential backoff: exponential backoff is the client's own best guess in the absence of server input, while Retry-After is a concrete signal from the party that actually knows the answer, and a well-designed client architecture treats server-provided timing as taking precedence over client-computed timing whenever both are available. ## Jitter and sanity checks still apply That said, honoring Retry-After doesn't mean abandoning jitter or sanity checks entirely. - If many clients hit the same rate limit at the same moment and all receive an identical Retry-After value, honoring it literally recreates the synchronized-retry problem jitter is meant to solve — so a robust client adds a small amount of jitter on top of the server-specified wait (e.g., `Retry-After + random(0, few seconds)`) rather than treating the header's value as a single precise instant to retry at. - There's also a defensive concern: a misbehaving or compromised server could return an extreme Retry-After value (hours or days), and a client that blindly waits that long risks violating its own caller's deadline or effectively hanging; well-behaved clients typically cap how long they're willing to wait based on the header, falling back to surfacing an error to the caller if the server-specified wait exceeds some sane ceiling or the caller's own deadline budget. ## When the header is absent When the header is absent — which is common, since not every API implements it even for 429/503 responses — the client has no choice but to fall back to its default exponential-backoff-with-jitter policy, since it has no server-provided signal to rely on. A robust retry implementation therefore checks for the header's presence first and only falls through to computed backoff when it's missing. It's also worth distinguishing Retry-After from status-code-based retry eligibility more broadly: a 429 or 503 is generally considered retryable, while a `400 Bad Request` or `404 Not Found` is not — retrying a malformed request or a genuinely nonexistent resource will simply fail again regardless of how long the client waits, so Retry-After handling and retry-eligibility classification (which status codes are worth retrying at all) are two separate but related pieces of a complete retry policy. ## Where it shows up A concrete real-world example is how most major cloud/API providers implement rate limiting: GitHub's REST API, for instance, documents returning a 403 or 429 with rate-limit headers when a client exceeds its request quota, and its own documentation instructs well-behaved clients to check these headers and back off accordingly rather than continuing to poll at the same rate — clients that ignore this guidance and keep hammering the API at their prior rate risk having their access token further throttled or temporarily blocked. The general pattern — server communicates its own recovery timing explicitly, client treats that as authoritative over its own guesswork — recurs across rate-limited public APIs, message brokers signaling backpressure, and load balancers returning 503 during rolling deployments.