# Handling Retry-After and temporary failures

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

Category: HTTP NOTES
Canonical: https://fieldnotesarchive.org/wiki/retry-after-and-backoff

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.

```text
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.