How much jitter to add to exponential backoff
Your backoff is doubling correctly but clients still retry in waves, and you need to know how much randomness to introduce.
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.
What jitter is fixing
Backoff spreads one client's attempts over time but leaves all clients synchronised: everyone who failed at the same moment computes the same delay and returns together. The retry storm reproduces the spike. Jitter breaks the correlation between clients, which is the actual problem.
Full against equal
Full jitter picks uniformly between zero and the cap, so some retries come back almost immediately. Equal jitter picks between half the cap and the cap, guaranteeing a floor. Full jitter recovers faster in aggregate; equal jitter avoids near-zero waits that are certain to fail again.
What not to do
Adding a small fixed random amount — the delay plus up to fifty milliseconds — is the common half-measure and it does not work. The spread has to scale with the delay, or a thousand clients still return inside the same narrow window.
Where jitter belongs in the schedule
Apply jitter to the delay before sleeping, not to the exponent. Randomising the exponent changes the growth curve and can produce a longer wait at attempt two than at attempt four, which is not what backoff is for. The cap should also be jittered, or every client that reaches the ceiling converges on the same interval again just as the earlier synchronisation is breaking up.
Jitter strategies at a 3.2 second computed delay
Jitter strategies at a 3.2 second computed delay
| Strategy | Wait range | Average | Spread |
|---|
| None | 3.2 s exactly | 3.2 s | none — clients synchronised |
| Fixed ±50 ms | 3.15-3.25 s | 3.2 s | negligible |
| Equal jitter | 1.6-3.2 s | 2.4 s | good, with a floor |
| Full jitter | 0-3.2 s | 1.6 s | complete |
Key facts
- Full jitter waits a uniform random time between zero and the computed delay, halving the average wait while spreading retries completely.
- Equal jitter waits half the computed delay plus a random half, which spreads slightly less but guarantees a minimum gap between attempts.
- Backoff without jitter leaves clients synchronised, so the retry wave reproduces the spike that caused the failure.
- A small fixed random offset does not work: the spread must scale with the delay or clients still return inside one narrow window.
- Jitter is only needed where more than one client can fail simultaneously, which in any multi-user system is always.
Frequently asked questions
Does full jitter make recovery slower?
It makes any single attempt less predictable and aggregate recovery faster, because the average wait is half the computed delay rather than all of it.
Should jitter apply to a Retry-After value?
Add a small amount after it, never before. Retrying earlier than the server asked defeats the header; returning together at the exact second it expires recreates the wave.
Should the maximum delay be jittered too?
Yes, and it is the most commonly missed part. Clients that reach an unjittered ceiling all retry at the same fixed interval from then on, which recreates the exact synchronisation the earlier jitter removed.
Machine-readable copy of this page:
/guide/how-much-jitter-to-add-to-backoff.md