Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
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. Each retry waits longer than the last by a fixed multiplier, up to a cap. This calculator prints the exact schedule, marks the retry where the cap takes over, and adds up what a caller could end up waiting, with and without jitter.
What it computes
delay(k) = min(cap, base × multiplier^(k − 1)) retry k = 1, 2, …
worst case = Σ delay(k) no jitter
full jitter = random in [0, delay(k)] mean = delay(k) / 2
equal jitter = random in [delay(k) / 2, delay(k)] mean = 0.75 × delay(k)- Base delay is the wait before the first retry, in milliseconds.
- Multiplier is the growth per retry; 2 doubles each time.
- Cap is the largest single wait allowed. Once
base × multiplier^(k − 1)passes it, every remaining retry waits exactly the cap. - Retry attempts sets how many rows to compute, from 1 to 20.
The jitter columns are ranges, because each real retry draws a fresh random delay. The headline expected total, full jitter and the footnote’s equal-jitter total are the sums of the means. Durations print in milliseconds, then seconds, then minutes and seconds.
A worked example
The defaults are a 100 ms base, a multiplier of 2, a 20,000 ms cap and 8 retries.
| Retry | No jitter | Full jitter range | Equal jitter range |
|---|---|---|---|
| 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 |
- Worst case:
100 + 200 + … + 12,800 = 25,500 ms, shown as 25.5 s. The cap never bites, because the largest delay is 12.8 s. - Full jitter averages half of each delay:
12,750 ms, shown as 12.8 s. - Equal jitter averages three quarters:
19,125 ms, shown as 19.1 s.
Raise the retries to 10 and the ninth retry would want 25.6 s, so the cap note appears at attempt 9, retries 9 and 10 both wait 20 s, and the worst case jumps to 65.5 seconds, shown as 1m 6s. Two extra attempts more than doubled the possible wait.
Assumptions and limits
- Waiting time only. The totals ignore how long each failed attempt itself takes. A request that times out after 5 seconds adds 5 seconds per retry on top of the schedule.
- Means, not samples. Jitter totals are averages. Any single client can wait anywhere inside the ranges, and the no-jitter column is the upper bound for both.
- Two jitter styles. Decorrelated jitter, which sets each sleep to
min(cap, random(base, previous × 3)), is not tabulated. - No retry policy. The tool does not decide which errors deserve a retry, honor a server’s Retry-After header or model a shared retry budget.
How to use the result
- Fit the worst case into your latency budget. If a user-facing call can wait 3 seconds in total, eight doubling retries from 100 ms cannot fit; use fewer retries or a lower cap.
- Always add jitter when many clients share a dependency, and default to full jitter.
- Retry only safe operations. Idempotent requests, or ones carrying an idempotency key, can be retried; others can double-charge or double-write.
- Pair retries with a circuit breaker or retry budget so a dependency that is truly down stops receiving retries instead of being buried by them.
How it works
- Delay before retry k = min(cap, base × multiplier^(k−1)).
- Full jitter draws each delay from [0, backoff]; equal jitter from [backoff / 2, backoff].
- Worst-case total wait sums the capped delays across every retry attempt.
- Shows where the cap takes over; up to 20 retries, computed in your browser.
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 100 ms, 200 ms, 400 ms, 800 ms 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, while still retrying quickly when the failure was a brief blip.
How do you calculate exponential backoff delays?
The delay before retry k is the base delay times the multiplier raised to k minus 1, limited by the cap. With a 100 ms base, a multiplier of 2 and a 20-second cap, the eight retries wait 100 ms, 200 ms, 400 ms, 800 ms, 1.6 s, 3.2 s, 6.4 s and 12.8 s, for a worst-case total of 25.5 seconds. A ninth retry would want 25.6 s, so the cap holds it at 20 s, and every later retry waits 20 s too.
Why add jitter to backoff?
Without jitter, many clients that failed at the same instant also retry at the same instant, producing synchronized spikes, often called 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, so each wait lands between half the backoff and the full backoff.
Full jitter vs equal jitter: which is better?
Full jitter spreads retries the most. In the widely cited AWS simulation of competing clients, it needed the fewest total calls, while equal jitter did more work and took longer to finish. Equal jitter guarantees a minimum wait, so a near-immediate retry never happens, at the cost of less spread. Full jitter is the usual default; equal jitter suits cases where a retry within a few milliseconds would itself be harmful. Decorrelated jitter is a third option that performed similarly well.
What should the cap and the retry count be?
Work backward from how long the caller can wait. The cap bounds any single sleep, and the retry count bounds how many sleeps there are, so together they set the worst-case total this calculator sums. Background jobs can afford caps of tens of seconds and many retries. User-facing requests usually need a small total, a few seconds at most, so use fewer retries and fail with a clear error rather than leaving someone staring at a spinner.