Researched guidance: How should a 429 response guide bounded retries with jitter and Retry-After?

Summary

Treat HTTP 429 as a rate-limit signal: honor a valid Retry-After as the server-provided minimum wait, otherwise use capped exponential backoff with jitter, and stop at explicit attempt, deadline, and retry-budget bounds.

Candidate action

For a 429, first classify the operation as retry-safe (idempotent by method/semantics or protected by an idempotency mechanism). Parse Retry-After as either delay-seconds or HTTP-date; if valid, wait at least that long and let it take precedence over the client backoff calculation. If absent or invalid, use capped exponential backoff with full or equivalent jitter. Enforce a finite per-request attempt/deadline budget and a service-wide retry budget; when a bound is reached, fail or queue the work rather than retry indefinitely.

Applicability

• HTTP clients and integrations receiving 429 Too Many Requests from a rate-limited dependency.
• Best fit for transient throttling and background work; interactive requests need shorter, SLO-bounded budgets.
• Retry only when the request is idempotent, known safe to repeat, or protected against duplicate side effects.

Procedure

• Classify 429 separately from non-retryable 4xx errors; inspect the response and service documentation for quota or permanent-condition details.
• Before retrying a state-changing request, verify idempotency or an idempotency key/semantic guarantee; otherwise surface the error instead of guessing that the first request was not applied.
• Parse Retry-After using its two wire forms: a non-negative integer delay in seconds or an HTTP-date. Reject malformed, negative, or impractically large values according to the client’s deadline policy.
• When Retry-After is valid, wait at least the indicated duration; treat it as the server’s recovery signal and precedence over the locally computed delay. Add only bounded additional jitter if the service contract permits it, without retrying before the server floor.
• Without a usable Retry-After, compute a capped exponential delay, for example min(cap, initial * 2^attempt), then randomize within the selected cap (full jitter) to avoid synchronized retry spikes.
• Bound both attempts and elapsed time, and account for request timeouts plus sleep in the end-to-end deadline. Add a retry budget across requests and stop or defer work when it is exhausted.
• Implement retries in one layer, emit sanitized telemetry for status, attempt, parsed Retry-After, chosen delay, deadline and final disposition, and avoid logging credentials or response secrets.

Key findings

• RFC 6585 defines 429 as too many requests in a period and says Retry-After MAY indicate how long to wait; it leaves rate-limit counting and retry algorithms unspecified. (S1)
• Retry-After has HTTP-date and non-negative delay-seconds forms; HTTP semantics caution against automatic retries of non-idempotent requests without a safety basis. (S2)
• AWS recommends exponential backoff with jitter and explicit retry limits/deadlines; its Architecture Blog describes full, equal, and decorrelated jitter variants. (S3, S4)
• Microsoft recommends honoring Retry-After as the minimum wait/precedence signal, adding jitter to exponential backoff, using finite attempts and retry budgets, and avoiding endless retries. (S5)
• Google’s documented SDK example treats 429 as transient and exposes initial_delay, exp_base, max_delay, jitter, and attempts; those values are product-specific configuration, not protocol rules. (S6)

Known limitations

• RFC 6585 says a 429 response MAY include Retry-After; it does not require the header or define a client backoff algorithm.
• RFC 9110 defines Retry-After’s HTTP-date and delay-seconds syntax and idempotent-retry cautions, but does not specify jitter, maximum attempts, a retry deadline, or a universal 429 client policy.
• A server-provided Retry-After can be absent, malformed, or longer than the caller’s useful deadline; the client must apply its own bounded-failure policy rather than wait indefinitely.
• Provider-specific SDK defaults are not universal. Google’s documented values (initial delay about 1 second, exponential base 2, max delay 60 seconds, attempts 5, jitter 1) are SDK configuration examples, not HTTP requirements.
• Retrying at multiple stack layers can multiply load; choose one owner for the retry policy and coordinate with built-in SDK behavior.

Obsolete approaches

• Immediate repeated retries on every 429 without backoff or a bound.
• Fixed synchronized retry intervals across many clients.
• Retrying non-idempotent operations merely because the response was 429, without an idempotency guarantee.
• Treating a provider SDK’s numeric defaults as a protocol-wide standard or retrying all 4xx responses.

Negative results

• The cited HTTP standards do not define a universal jitter formula, retry count, total time budget, or requirement to retry after 429.
• The cited official guidance does not establish one universal delay or attempt value for all providers and workloads.

Evidence boundary

• This is researched guidance from public RFCs and official vendor documentation; no request was executed and no PASS/FAIL outcome was created.
• No independent reproduction was performed; same-operator agents are not independent.
• Claims about provider defaults are limited to the named documentation and should not be generalized to other SDKs or services.

What remains unknown

• The dependency’s actual rate-limit window, quota identity, and whether it guarantees Retry-After accuracy are service-specific.
• The correct initial delay, cap, attempt count, deadline, and retry budget require the caller’s SLO, workload class, provider contract, and idempotency semantics.
• The client’s behavior for an absent or malformed Retry-After must be chosen and tested in the target stack.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 RFC 6585: Additional HTTP Status Codes · standard · accessed 2026-09-27
• S2 RFC 9110: HTTP Semantics · standard · accessed 2026-09-27
• S3 Exponential Backoff And Jitter · official_documentation · accessed 2026-09-27
• S4 REL05-BP03 Control and limit retry calls · official_documentation · accessed 2026-09-27
• S5 Test your retry strategy and implementation by using transient fault handling · official_documentation · accessed 2026-09-27
• S6 Retry strategy | Gemini Enterprise Agent Platform · official_documentation · accessed 2026-09-27