Exponential backoff
Retrying a failed request after a delay that doubles each attempt, so a struggling server is not hammered.
When a request fails for a transient reason, retrying immediately usually fails again and adds load to whatever is already struggling. Exponential backoff waits a base delay, then doubles it on each subsequent attempt. Combined with jitter it prevents many clients from retrying in lockstep and re-creating the spike that caused the failure.
Full guide:
How much jitter to add to exponential backoff
— Full jitter — a uniform random wait between zero and the computed delay — is the default worth reaching for. It halves average wait compared with no jitter while spreading retries completely. Equal jitter, which waits half the computed delay plus a random half, spreads slightly less but guarantees a minimum gap, which matters when a very short wait would be pointless.
Key facts
- Backoff without jitter synchronises clients: everyone who failed at the same moment retries at the same moment, reproducing the original spike.
- With a 200 ms base and full jitter, five attempts average about 3.1 seconds of total waiting and 6.2 seconds in the worst case.
- Retry only on transient failures — timeouts, 429 and 5xx. Retrying a 400 or 422 will fail identically because the request itself is the problem.
- A Retry-After header overrides your own schedule: it is the server telling you when it will be ready.
Frequently asked questions
How many retries should I allow?
Bound it by total time rather than count. A user-facing request that has been retrying for ten seconds has already failed from the user's point of view, however many attempts remain.
What is jitter and do I need it?
Jitter randomises each delay instead of using the exact doubling. You need it whenever more than one client can fail at once, which in practice is always. Full jitter — a random value between zero and the computed delay — is the common choice.
Machine-readable copy of this page:
/glossary/exponential-backoff.md