Exponential backoff calculator
Set the first delay, the multiplier, a maximum delay and the number of retries to see the schedule your retry loop will follow, how long a request may wait in total, and what full or equal jitter does to it.
Runs in your browser: nothing you enter is sent anywhere.
How to use it
- Enter the first delay in milliseconds and the multiplier (2 doubles each time).
- Set the maximum delay, or 0 for none, and the number of retries.
- Choose a jitter strategy and read the table and the totals.
delay(n) = min(maximum, first delay × multiplier^(n − 1))
With full jitter the actual delay is random in [0, delay(n)]; with equal jitter it is random in [delay(n) ÷ 2, delay(n)]. The totals add the shortest, average and longest values of each retry.
Worked example
First delay 500 ms, multiplier 2, maximum 30 s, 8 retries: the delays are 0.5, 1, 2, 4, 8 and 16 s, then 32 s and 64 s are both capped to 30 s. The longest total wait is 0.5 + 1 + 2 + 4 + 8 + 16 + 30 + 30 = 91.5 s, shown rounded as 1 min 32 s. With full jitter the average total is half of that, 45.75 s.
Tips
- Respect a Retry-After header when the server sends one; it overrides your schedule.
- Put an overall deadline on the loop as well as a retry count.
- Log the attempt number so you can see in production how often retries happen.
Frequently asked questions
What is exponential backoff?
A retry strategy where each wait is longer than the last, usually doubling. A failing service gets breathing room, and clients do not hammer it with retries. The delay before retry n is the first delay × multiplier^(n − 1), limited by the maximum.
Why add jitter?
When many clients fail at the same moment, identical schedules make them retry at the same moments too. Jitter spreads them out. Full jitter picks a random delay between 0 and the computed one; equal jitter keeps half of it and randomises the other half.
What maximum delay should I use?
It depends on how long the caller can wait. Interactive requests usually cap at a few seconds and give up after a handful of retries; background jobs can wait minutes. The total wait here shows whether the schedule fits your timeout.
Should every error be retried?
No. Retry timeouts, connection errors and responses such as 429 or 503 that signal a temporary problem. Errors like 400 or 404 will fail again. Only retry operations that are safe to repeat, or make them idempotent first.