~/retry-backoff-calculator

> Retry Backoff Calculator

Visualize exponential backoff with jitter for API retry logic. Tune attempts, base delay, multiplier, cap, and jitter strategy; get a per-attempt delay table, the total worst-case wait, and a copyable JavaScript implementation. No external dependencies, everything runs in your browser.

Inputs

1 to 20
must be at least 1
growth per attempt
upper bound per sleep
how sleeps are randomized
Worst-case total wait
-
Expected total wait
-
Final attempt max delay
-

Sleep range per attempt

Bars are scaled to the largest max sleep. solid = guaranteed minimum, striped = random jitter range up to the max. Each bar is labeled with its max sleep; hover for exact numbers.

Delay table

Attempt Raw delay (ms) Min sleep (ms) Expected (ms) Max sleep (ms) Cumulative worst case

JavaScript snippet (current settings)

Why this matters

Why retry storms happen

When a service blips, every client that got an error retries. If they all retry on the same fixed schedule, the original burst of traffic replays as synchronized waves. Each wave slams into a service that is already struggling, so the wave fails too, and the retries themselves keep the service down. That feedback loop is a retry storm.

Why jitter prevents the thundering herd

Exponential backoff spreads the waves further apart in time, but it keeps clients synchronized: everyone who failed at the same moment comes back at the same instants. Jitter adds randomness so retries land spread across the whole window instead of stampeding at once. Full jitter, popularized by the AWS Architecture Blog analysis, tends to reduce contention and total completed work the most; equal jitter trades some of that spread for a guaranteed minimum wait; decorrelated jitter randomizes based on the previous sleep instead of the attempt number.

Why you cap the delay

Without a cap, a multiplier of 2 turns a 250 ms base into over four minutes of sleep by attempt 11. A cap keeps worst-case latency bounded, so callers time out predictably and request queues do not back up behind one very patient client. Pick the cap from your caller's timeout budget, not from the math.

Retries are only safe on idempotent operations

A retry re-runs the operation. That is only safe when running it twice has the same effect as running it once: reads, upserts keyed by a client-generated id, or writes guarded by an idempotency key. Blindly retrying a "charge the card" or "send the email" call can double the side effect. This calculator pairs with idempotency-and-safe-retries-reference in the same portfolio, which covers how to make operations safe to retry in the first place.