{"type":"reference","slug":"retry-after-and-backoff","category":"HTTP NOTES","title":"Handling Retry-After and temporary failures","summary":"A small checklist for clients that encounter 429 or 503 responses.","updated_at":"2026-09-04T18:20:00.000Z","canonical_url":"https://fieldnotesarchive.org/wiki/retry-after-and-backoff","alternate":{"markdown":"https://fieldnotesarchive.org/wiki/retry-after-and-backoff.md","json":"https://fieldnotesarchive.org/wiki/retry-after-and-backoff.json"},"content_markdown":"# Handling Retry-After and temporary failures\n\nA small checklist for clients that encounter 429 or 503 responses.\n\nCategory: HTTP NOTES\nCanonical: https://fieldnotesarchive.org/wiki/retry-after-and-backoff\n\nA server can send `Retry-After` to indicate how long a client should wait before making a follow-up request. The value may be a number of seconds or an HTTP date.\n\n```text\nHTTP/1.1 429 Too Many Requests\nRetry-After: 60\n```\n\n## Bound the retry loop\n\nFor operations that are safe to retry, use a retry count and an overall deadline. Where no valid server delay is present, increasing delays with jitter can reduce synchronized retries. If a server delay exceeds your deadline, stop rather than retrying earlier than requested.\n\n## Writes need extra care\n\nA connection error does not prove that a write failed. The server may have committed a change before the response was lost. Retry writes only when the operation is idempotent or when the API provides a documented deduplication mechanism.\n\n## Keep enough context\n\nRecord the response status, retry count and elapsed time. Avoid including authorization headers or sensitive request bodies in diagnostic logs.\n"}