Retry Policy Calculator

Calculate total retry latency and load amplification from a retry policy configuration.

About Retry Policy Calculator

Exponential backoff increases the delay between retry attempts geometrically: delay = min(initial_delay × multiplier^(attempt-1), max_delay_cap), so each retry waits longer than the last up to a ceiling that prevents unbounded delays. Summing the delay schedule across all retries gives the maximum total time a caller might wait before the final attempt either succeeds or the retry budget is exhausted — critical for setting realistic upstream timeouts that accommodate the full retry sequence.

Formula

max_total_time_sec = initial_delay × (backoff_multiplier^max_retries - 1) / (backoff_multiplier - 1)

initial_delay: First retry delay (seconds)
backoff_multiplier: Exponential backoff factor
max_retries: Maximum number of retry attempts

Worked example

With the default values below, Retry Policy Calculator returns Max Total Retry Time of 1.50. Change any input above and every figure here is recalculated in your browser.

Inputs used

Max Attemptsaccepts 1–50 attempts: 5 attempts
Initial Delayaccepts 1–1,000,000 ms: 100 ms
Backoff Multiplieraccepts 1–10 ×: 2 ×
Max Delay Capaccepts 1–10,000,000 ms: 10,000 ms

Results

Max Total Retry Time: 1.50 seconds
Number of Retries: 4
Final Retry Delay: 800 ms
Capped by Max Delay: false

Step by step

1Attempt 1 delay= 100ms (cumulative 100ms)
2Attempt 2 delay= 200ms (cumulative 300ms)
3Attempt 3 delay= 400ms (cumulative 700ms)
4Attempt 4 delay= 800ms (cumulative 1500ms)

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why cap the maximum delay instead of letting it grow indefinitely?

Uncapped exponential growth can quickly produce impractically long waits (e.g. attempt 10 at a 2x multiplier from 100ms would be over 50 seconds) — a cap keeps worst-case latency bounded while still spacing out retries to avoid overwhelming a struggling dependency.

Should I add jitter to this backoff schedule?

Yes, in production — this calculator shows the deterministic backoff schedule, but adding random jitter (e.g. ±20%) to each delay prevents many clients that failed at the same time from retrying in synchronized waves, which can cause a 'thundering herd' against the recovering service.

How does retry count relate to max attempts?

max_attempts includes the original attempt, so retry_count = max_attempts − 1; a max_attempts of 5 means 1 initial try plus 4 retries, following the exponential backoff schedule for each retry.

How should timeout configuration account for retries?

Any upstream timeout wrapping a call that includes retries must be at least as long as the max total retry time shown here, plus the per-attempt request timeout itself — otherwise the outer timeout will fire before the retry policy has a chance to exhaust its attempts.