Exponential Backoff Calculator

How to use

1. 1Pick a preset (AWS, GCP, gRPC, Polite, Aggressive, Near-linear) to drop in a tested policy, or start tuning the four inputs from defaults.
2. 2Set the Base delay in milliseconds (the wait before the first retry), Growth factor (multiplier per attempt), Maximum delay (per-attempt cap), and Retries (1 to 25).
3. 3Choose a Jitter strategy: None for textbook deterministic delays, Full to spread across the whole window, Equal to guarantee half the deterministic wait, or Decorrelated for the AWS recommendation.
4. 4When jitter is on, set a Random seed (any word or number works) for reproducible samples. Click Reroll seed to draw a different sample.
5. 5Read the Total wait pill for the time window before the policy gives up, scan the Schedule table for per-attempt delay ranges and the seeded sample, and watch the inline bar chart for jitter spread and capped attempts.
6. 6Click Copy schedule to grab a plain-text report ready to paste into a runbook, code review, ticket, or test fixture.

About this tool

Exponential Backoff Calculator plans the retry schedule for an API client, a queue consumer, or any caller that needs to back off after a transient failure. Pick a base delay (the wait before the first retry), a growth factor (the multiplier per attempt), a per-attempt cap (so a single retry cannot stall the whole request), and the number of retry attempts. The tool emits one row per retry with the delay before that attempt, the running cumulative wait, and the total time before the policy gives up. Four jitter strategies are supported, all matching the names developers see in real SDK configuration: None is the deterministic textbook formula min(cap, base times factor to the power of attempt) used in classroom examples; Full jitter draws a uniform random value between zero and the capped exponential delay, the safest choice for killing a thundering herd because every client lands at a different point in the window; Equal jitter guarantees at least half of the deterministic wait and adds a uniform half on top, a common AWS SDK middle ground that bounds the worst case without removing all randomness; Decorrelated jitter draws from uniform(base, previous delay times three) and feeds the result into the next attempt, the strategy recommended by the AWS Architecture Blog post Exponential Backoff And Jitter for retries that should stay close to the cap longer without drifting back to zero. The result panel reports the total wait window as a min and max range (because jitter has a deterministic interval even though each sample is random) and a seeded sample that uses a small Mulberry32 PRNG so the schedule can be pasted into a runbook, a code review, or a unit test and reproduced exactly. A horizontal bar chart per row shows the jitter window and where the seeded sample landed inside it. Six presets drop in policies you have probably configured already: AWS SDK default (100 ms base, 2x growth, 20 s cap, 3 retries, equal jitter); Google Cloud client (1 s base, 1.3x growth, 60 s cap, 5 retries, full jitter); gRPC default policy (1 s base, 1.6x growth, 120 s cap, 5 retries, full jitter); Polite API client (250 ms base, 2x growth, 30 s cap, 5 retries, decorrelated); Aggressive retry (50 ms base, 2x growth, 5 s cap, 10 retries, no jitter); and Near-linear backoff (500 ms base, 1.5x growth, 10 s cap, 6 retries, equal jitter). Inline warnings catch caps smaller than the base, growth factors below one that would shrink the wait, and impossible configurations before the table is rendered. Useful for backend engineers tuning HTTP clients, SREs writing runbooks for rate-limited third-party APIs, mobile and frontend developers handling flaky network conditions, queue operators sizing dead-letter timeouts, and integration teams sanity-checking how long a policy can keep a request alive. All math runs in your browser; nothing is uploaded.

Free to use. Works in your browser. No signup, no login.