Retry Budget Planner

How much extra traffic and cost a retry policy adds on a normal day, how much failure it actually removes, and how far it multiplies load during an outage.

Baseline failure rateShare of attempts that fail on a normal day — 5xx, timeouts, 429s.

Retries after the first attempt2 means up to three attempts in total.

Retry budgetExtra traffic you are willing to add on top of first attempts. A client-side retry budget enforces this as a rolling cap.

Requests per dayFirst attempts, before retries.

Cost per requestYour own average cost for one attempt, in USD. The example is a placeholder — put your own figure in.

USD

Retries your budget affords

10+

At a 2.00% failure rate your 10.00% budget is not the constraint: 2 retries adds only 2.04% extra traffic. The constraint is the outage case — every client retrying to the cap multiplies load ×3.0.

Attempts per request, worst case: 3
Expected attempts per request: 1.0204
Extra traffic added: 2.04%
Failure rate after retries: 0.00080%
Failures per day, before retries: 2,000
Failures per day, after retries: 1
Extra requests per day: 2,040
Extra cost per day: $8.16
Extra cost per 30 days: $244.80
Load multiplier during a full outage: ×3.0
Retries inside your budget: 10+

What this assumes: Failures are treated as independent, which is the assumption that breaks exactly when it matters: the failures you actually meet are correlated, because a provider is down for everybody at once. Under correlation the residual figure above is far too optimistic and the outage multiplier is the honest number. A month is 30 days. Retries of a request that did complete server-side are billed twice, so the cost rows are a floor. Nothing here models the queueing an overloaded dependency is already suffering, which retries make worse.

Retries are cheap until the moment they are not

expected attempts = 1 + p + p² + … + p^retries
residual failure rate = p^(retries + 1) · outage multiplier = retries + 1

At a low failure rate the arithmetic is flattering. Two per cent failures with two retries adds about two per cent to your traffic and takes the user-visible failure rate to under a thousandth of a per cent. That is the calculation everyone does, and on a normal day it is correct — which is why retry counts get set once and never revisited.

The number that matters is the other one. When the dependency is genuinely down, p is not two per cent, it is one hundred, and the geometric series collapses to its worst case: every client sends every attempt, and the failing service receives three times its normal load at precisely the moment it has least to give. Retries do not recover anything in that state — they are pure amplification, and they are a well-documented way to convert a partial outage into a total one.

That is what a retry budget is for. Instead of a fixed count per request, you cap retries as a share of recent traffic — a rolling window that allows plenty of retries while failures are rare, and approaches zero once they are widespread. Pair it with full jitter on the backoff so clients do not resynchronise into waves, and only retry what is worth retrying: a 429 with a Retry-After, a connection reset, a 503. Retrying a 400 just spends money to receive the same rejection three times.

Retry Budget Planner

Retries are cheap until the moment they are not

The reasoning behind this

Related tools