Retry Policy Calculator

Calculate the exponential backoff delay schedule and maximum total time for a retry policy given max attempts and initial delay.

Inputs

Max Attemptsattempts

Maximum number of attempts including the initial try (so max_attempts − 1 retries).

Initial Delayms

Delay before the first retry attempt.

Backoff Multiplier×

Multiplier applied to the delay after each attempt (2 = classic exponential backoff).

Max Delay Capms

Ceiling applied to any single retry delay, regardless of exponential growth.

Max Total Retry Time

1.50seconds

Number of Retries

Final Retry Delay

800ms

Capped by Max Delay

false

Step by step

Attempt 1 delay
min(100 × 2^0, 10000)
= 100ms (cumulative 100ms)
Attempt 2 delay
min(100 × 2^1, 10000)
= 200ms (cumulative 300ms)
Attempt 3 delay
min(100 × 2^2, 10000)
= 400ms (cumulative 700ms)
Attempt 4 delay
min(100 × 2^3, 10000)
= 800ms (cumulative 1500ms)

How it works

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

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.

You might also need

Circuit Breaker Threshold Calculator Timeout Configuration Calculator Service Mesh Health Score Calculator