Calculate total retry latency and load amplification from a retry policy configuration.
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.
max_total_time_sec = initial_delay × (backoff_multiplier^max_retries - 1) / (backoff_multiplier - 1)
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.
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.
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.
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.