HTTP NOTES

Handling Retry-After and temporary failures

A small checklist for clients that encounter 429 or 503 responses.

A 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.

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Bound the retry loop

For 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.

Writes need extra care

A 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.

Keep enough context

Record the response status, retry count and elapsed time. Avoid including authorization headers or sensitive request bodies in diagnostic logs.

Alternate formats: Markdown · JSON

← Reference index