Retry Policy Generator

Base delay, multiplier and failure rate in; the delay of every attempt, the chance of eventual success, the worst-case latency and working code out.

Base delayThe wait before the first retry.

Multiplier2 doubles each time. 1 means a fixed delay.

Total attemptsIncluding the first. 4 means one try and three retries.

attempts

Delay capNo single wait exceeds this. 0 for no cap.

Jitter

Generated code

Failure rate per attemptYour own measured rate of retryable failures — 429s and 5xx, not bad requests.

Mean latency of one attemptIncluding the failed ones, which are often the slow ones.

DeadlineWhen something upstream — a user, a gateway, a queue — stops waiting.

Chance the call eventually succeeds

99.9959%

Up from 92.0% with no retries, if failures are independent. Worst case 8.30 s; expected 1.33 s.

Wait before attempt 2: 0 ms – 500 ms (mean 250 ms)
Wait before attempt 3: 0 ms – 1.00 s (mean 500 ms)
Wait before attempt 4: 0 ms – 2.00 s (mean 1.00 s)
Total waiting, worst case: 3.50 s
Total waiting, expected: 24 ms
Expected attempts per request: 1.087
Extra calls per successful request: 0.087
Load multiplier on the provider: 1.09×
Expected end-to-end time: 1.33 s
Worst-case end-to-end time: 8.30 s
Failure rate after retries: <0.1%
Attempts that fit in the deadline: 4 of 4

PythonRead-only. Select all and copy.

import random, time

BASE_MS     = 500
MULTIPLIER  = 2
MAX_ATTEMPTS= 4
CAP_MS      = 20000
DEADLINE_S  = 30

RETRYABLE = {408, 409, 425, 429, 500, 502, 503, 504}

def call_with_retry(send, *, deadline_s: float = DEADLINE_S):
    """send() -> response with .status_code and .headers. Raises on give-up."""
    started = time.monotonic()
    last = None
    for attempt in range(1, MAX_ATTEMPTS + 1):
        try:
            r = send()
            if r.status_code < 400 or r.status_code not in RETRYABLE:
                return r            # success, or a failure retrying cannot fix
            last = r
        except (TimeoutError, ConnectionError) as e:
            last = e
        if attempt == MAX_ATTEMPTS:
            break

ceiling = min(CAP_MS, BASE_MS * MULTIPLIER ** (attempt - 1))
        delay = random.random() * ceiling
        # Retry-After is the server telling you exactly how long to wait.
        # It always wins over your own arithmetic.
        retry_after = getattr(last, "headers", {}).get("Retry-After") if last is not None else None
        if retry_after:
            try:
                delay = max(delay, float(retry_after) * 1000)
            except ValueError:
                pass                 # an HTTP-date form; parse it if you meet one

if (time.monotonic() - started) + delay / 1000 > deadline_s:
            break                    # no point sleeping past the deadline
        time.sleep(delay / 1000)

raise RuntimeError(f"gave up after {MAX_ATTEMPTS} attempts: {last!r}")

What this assumes: failures are independent — each attempt fails with the same probability, regardless of the ones before it. That is roughly true of a busy service shedding load and completely false during an outage, where every attempt fails and the only effect of the policy is the delay column. So read the success probability as an upper bound and the worst-case time as the number that will actually happen on your worst day. Delays are measured from the end of the failed attempt, so the end-to-end figures add 1200 ms of latency per attempt on top of the waiting. Retry-After, where a server sends it, overrides all of this — the generated code honours it. Everything on this page runs in your browser. Nothing you paste or open is uploaded, logged or sent anywhere.

A retry policy is two decisions that pull against each other: how much extra latency you will spend to turn a transient failure into a success, and how much extra load you will put on a service that is already failing. Everything above is those two numbers made explicit. The success probability climbs steeply for the first two retries and then barely moves; the worst-case latency keeps climbing the whole time. That is why four attempts is a common answer and ten is almost never one.

Jitter is not an optimisation

Without it, every client that failed during the same second retries during the same second, then again together, then again — the thundering herd that turns a brief overload into a sustained one. Full jitter spreads the same requests across the whole window and costs you, on average, half the delay you had budgeted. There is essentially no situation in which not jittering is the better choice.

Retry the things that retrying can fix

429, 500, 502, 503, 504 and connection failures are worth retrying. A 400 will be a 400 every time, and a 401 will be a 401 until someone fixes the key; retrying either just multiplies a bug by four. The generated code has that list at the top so you can argue with it, and it honours Retry-After, which is the server telling you the answer this whole page is estimating.

Retry Policy Generator

Jitter is not an optimisation

Retry the things that retrying can fix

The reasoning behind this

Related tools