Enter your base delay, multiplier, cap, jitter mode, and attempt count. Instantly see every retry delay, the best- and worst-case total wait, cumulative success probability, and copy-ready config snippets for popular retry SDKs.
| Attempt | Raw delay | Min (jitter) | Max (jitter) | Expected | Cumul. success |
|---|
Exponential backoff spaces out retries so a struggling service isn't hammered by a stampede of clients. The un-jittered delay for attempt n (1-indexed) is a capped geometric series:
Raw exponential growth alone creates a thundering herd: every client that failed at the same instant retries at the same instant. Jitter breaks that synchronization. This tool implements the four canonical strategies from the AWS Architecture Blog:
delay(n), easiest to reason about but herd-prone.random(0, delay(n)). Maximum spread, lowest contention.delay/2 + random(0, delay/2). Keeps a floor while still spreading.min(cap, random(base, prev×3)), where each delay depends on the previous one for a smoother, self-widening walk.The success-odds model assumes each attempt fails independently with probability p. The chance that at least one of k attempts succeeds is 1 − pk, and the expected number of attempts before a success (bounded by your max) is Σ p(i−1). Use these to decide whether adding another retry is worth the extra worst-case latency: the marginal success gain shrinks geometrically while your worst-case wait keeps climbing. Best-case total wait assumes the minimum jittered delay each round; worst-case assumes the maximum. For deterministic mode both collapse to the same number. All math runs locally in your browser — nothing is sent anywhere.