HTTP Retry-After & Date Calculator
Convert HTTP 429 Too Many Requests and 503 Service Unavailable delay headers into exact local unlock timestamps, track cooldowns with a live timer, and export exponential backoff with full jitter code.
// Generating retry snippet...RFC 9110 Retry-After Semantics & Best Practices
According to RFC 9110 Section 10.2.3, the Retry-After response header indicates how long the user agent ought to wait before making a follow-up request. It appears primarily in two HTTP status codes:
1. HTTP 429 (Rate Limiting)
Informs the client that its request quota or concurrency limit has been exceeded. The value indicates when the rate limit token bucket will refill.
2. HTTP 503 (Planned Maintenance / Overload)
Informs clients and search engine crawlers (Googlebot) that downtime is temporary. Search engines will not de-index pages if 503 is accompanied by a valid Retry-After header.
3. Delta-Seconds vs HTTP-Date
Retry-After: 120 specifies a relative delay in seconds.
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT specifies an absolute UTC timestamp (IMF-fixdate format).
4. The "Thundering Herd" & Full Jitter
When hundreds of clients receive Retry-After: 60 and all retry exactly at second 60, the synchronized spike crashes the recovering server.
Adding randomized jitter spreads the retry traffic smoothly over time.
Frequently Asked Questions
What happens if a client ignores Retry-After?
APIs and WAF layers (Cloudflare, AWS WAF) frequently escalate enforcement for clients that ignore 429 retry headers, converting temporary rate limits into prolonged IP bans (403 Forbidden).
Why is Full Jitter recommended over Equal Jitter?
AWS Architecture research proves that Full Jitter (sleep = random_between(0, base_delay)) yields the lowest overall API server contention and minimizes total completion time for large fleets of concurrent microservices.