Retry Patterns
What is safe to retry
Section titled “What is safe to retry”| Condition | Retry? |
|---|---|
429 Too Many Requests | Yes, after the Retry-After header’s timestamp. |
5xx Server Error | Yes, with exponential backoff. |
4xx Client Error (non-429) | No — the request is malformed or unauthorised. Fix it and resubmit. |
| Network error (no response) | Yes, with exponential backoff, but consider idempotency (see below). |
Backoff
Section titled “Backoff”For 5xx and network errors, use exponential backoff with jitter. A simple starting point:
- Wait
min(cap, base * 2^attempt) * random(0.5, 1.5)seconds between retries. base = 1s,cap = 30s, max ~5 attempts.
For 429 responses, do not back off linearly — respect the Retry-After
header’s timestamp and wait until that time before retrying.
Idempotency
Section titled “Idempotency”Retrying a network error (a lost connection after the request was sent) is only safe if the endpoint is idempotent — otherwise, you risk creating a duplicate resource.