Backoff & Jitter Calculator
Compute an exponential backoff schedule and see how full, equal, and decorrelated jitter spread the retries. Client-side, nothing is retried.
This tool runs in your browser. No data leaves your device.
| Attempt | Min | Max |
|---|
How It Works
Retries without jitter are how a transient blip becomes an outage. This works out the delay schedule for exponential backoff and shows how each jitter strategy spreads it across attempts. It only computes — it never retries anything.
The formula
Exponential backoff is delay = min(cap, base × factorⁿ⁻¹) for attempt n:
- base — the first wait (e.g. 100 ms).
- factor — the growth per attempt (
2doubles each time). - cap — the ceiling, so the wait doesn’t grow unbounded. Without a cap,
base 100ms × 2reaches ~3.4 minutes by attempt 12.
Why jitter — the thundering herd
If a thousand clients back off on the same schedule, they retry in synchronized waves — the very spike that knocked the service over, repeated on a timer. Jitter desynchronizes them by randomizing the wait.
- Full — uniform in
[0, delay]. Maximum spread; a client may retry very soon. - Equal — uniform in
[delay/2, delay]. Keeps a floor so nobody hammers instantly, but still spreads the herd. - Decorrelated — the next wait is uniform in
[base, previous × 3], capped. It adapts to the last sleep and is a strong general default. - None — the bare synchronized schedule. Fine for a single client; dangerous for a fleet.
Reading the table
Min/Max is the range a given attempt’s wait can fall into. For None, min equals max. The summary’s worst-case total wait sums the maximum of every attempt — the longest a client could wait in total before giving up after N tries. Watch how Full and Equal pull the minimum down while the maximum — and so the worst-case total — stays exactly where None leaves it. Decorrelated widens the range instead: its floor sits at base while its ceiling climbs past None’s, so its worst-case total is larger, not smaller. What takes load off a recovering service is that spread across the range, not a shorter total.
A retry is also how the same message gets delivered twice, so the handler on the other end has to be idempotent: see the BabelQueue idempotency spec and the runnable idempotency-payments example.
Privacy
Everything runs in your browser. No inputs leave the page.