Exponential Backoff Calculator
An interactive exponential-backoff calculator. Set the base delay, multiplier, cap and retry count, then see the exact delay before every retry attempt, the worst-case total wait, and how full and equal jitter change the numbers — so you can size retries that recover fast without hammering a service that is already struggling.
Delay before each attempt
| # | No jitter | Full jitter 0 … delay | Equal jitter ½ … full |
|---|---|---|---|
| 1 | 100 ms | 0 – 100 ms | 50 ms – 100 ms |
| 2 | 200 ms | 0 – 200 ms | 100 ms – 200 ms |
| 3 | 400 ms | 0 – 400 ms | 200 ms – 400 ms |
| 4 | 800 ms | 0 – 800 ms | 400 ms – 800 ms |
| 5 | 1.60 s | 0 – 1.60 s | 800 ms – 1.60 s |
| 6 | 3.20 s | 0 – 3.20 s | 1.60 s – 3.20 s |
| 7 | 6.40 s | 0 – 6.40 s | 3.20 s – 6.40 s |
| 8 | 12.8 s | 0 – 12.8 s | 6.40 s – 12.8 s |
Expected total with equal jitter: 19.1 s. Jitter values are the statistical mean and range — each real retry draws a fresh random delay inside that range.
Exponential backoff is the standard way to retry a failed request without making the failure worse. Instead of retrying at a fixed interval, each attempt waits longer than the last by a fixed multiplier — most commonly doubling — so the delays grow as base, base×2, base×4, base×8, and so on. A cap (maximum delay) stops the wait from growing without bound, so after enough failures every attempt waits the same capped amount. Formally, the delay before attempt n is min(cap, base × multiplier^n), counting from n = 0. This calculator prints that exact schedule, marks the attempt where the cap kicks in, and sums the delays into a worst-case total wait so you can see the real latency a long retry loop can add.
Plain exponential backoff has a hidden failure mode: when a service briefly goes down, thousands of clients fail at nearly the same moment, so they also retry at nearly the same moment — and then again in lockstep on the next attempt. Those synchronized waves, the “thundering herd” or “retry storm,” can keep the service pinned down long after the original blip. Jitter fixes this by randomizing each delay. With full jitter each wait is a uniform random value in [0, backoff], which spreads retries the most; with equal jitter half the backoff is fixed and half is random, in [backoff / 2, backoff], guaranteeing a minimum wait. A third variant, decorrelated jitter, feeds the previous delay back in (min(cap, random(base, prev × 3))) to spread retries while still trending upward. The tool shows the expected value and the range for full and equal jitter alongside the no-jitter schedule.
Sizing backoff is a trade-off between recovering quickly and not amplifying an outage. A larger multiplier or cap is gentler on a struggling dependency but slower for the caller; more retries improve the odds of eventually succeeding but stretch the worst-case latency, which for a user-facing request is often worse than failing fast. Read the worst-case total here as the maximum a caller could wait before giving up, then decide whether that fits your latency budget — and remember that retries should also be paired with a retry budget or circuit breaker so a truly-down dependency does not get retried forever. The numbers are exact for the schedule you enter; the right values still depend on your specific service, SLOs and how costly a slow retry is versus a fast failure.
How it works
- Delay before attempt n = min(cap, base × multiplier^n), for n = 0, 1, 2, …
- Full jitter randomizes each delay in [0, backoff], while equal jitter uses [backoff / 2, backoff].
- Worst-case total wait sums the capped delays across every retry attempt.
- All math is exact and runs in your browser — nothing is sent anywhere.
Frequently asked questions
What is exponential backoff?
Exponential backoff waits progressively longer between retries: each attempt multiplies the previous delay (typically doubling), so a failing request backs off as 100ms, 200ms, 400ms, 800ms, and so on. A cap keeps the delay from growing without bound. The point is to give a struggling or rate-limited service room to recover, instead of hammering it at a fixed interval and keeping it down.
Why add jitter to backoff?
Without jitter, many clients that failed at the same instant also retry at the same instant, producing synchronized spikes — a thundering herd, or retry storm — that can keep the service overloaded. Jitter randomizes each delay so retries spread out over time. Full jitter picks a delay uniformly between zero and the current backoff; equal jitter keeps half the backoff fixed and randomizes the other half.
What should the cap (maximum delay) be?
The cap bounds the worst case so a client does not sleep for minutes after a long run of failures. A common choice is 20 to 60 seconds for background work, and lower for user-facing calls where you would rather give up quickly and show an error. The cap together with the maximum retry count sets your total worst-case latency, which is the number this calculator sums for you.
Full jitter vs equal jitter — which is better?
Full jitter (a delay anywhere from zero to the current backoff) spreads retries the most, and in the widely-cited AWS study it minimized both wasted client work and server contention. Equal jitter (half the backoff fixed, half random) guarantees a minimum wait so an almost-immediate retry never happens, at the cost of slightly less spread. Full jitter is the usual default; equal jitter suits cases where a near-zero retry delay would itself be harmful.