Retry Backoff Schedule Generator

What this generator does

Computes a schedule rather than naming a value, which is where the dev-utilities category was thin. The status code and identifier generators return one thing; this answers a question with arithmetic in it — how long six exponential retries from 200ms actually take, and what changes when you cap them at ten seconds.

How to use this tool

1. Choose a strategy and set the base delay.
2. Set how many attempts and whether there is a cap.
3. Add jitter if clients should not retry in lockstep.
4. Press Generate schedule and read the elapsed column.

Understanding the controls

Strategy

Exponential doubles each time and is the usual default. Linear adds the base each time and grows far more slowly. Fixed never changes. Fibonacci sits between exponential and linear, and is used where doubling escalates too fast.

Base delay

The first wait, from which everything else grows. Doubling it doubles the whole schedule, which is the single biggest lever on the total.

Attempts

Including the first, which waits nothing — an important detail, because six attempts means five waits rather than six.

Cap

An upper bound on any single wait. Once it bites, every later retry waits the same amount, so the schedule stops growing and starts adding a constant. Zero means no cap.

Jitter

Randomises each delay either way by up to this percentage. Without it, every client that failed at the same moment retries at the same moment, which is how an outage turns into a second outage the instant a service recovers.

Worked examples

Six exponential retries from 200ms

0, 200, 400, 800, 1600, 3200 — 6.2 seconds in total.

The same capped at 1 second

0, 200, 400, 800, 1000, 1000 — 3.4 seconds, and the growth stops at attempt five.

Ten attempts from 1 second

Over eight minutes without a cap, which is almost never what anyone intended.

Common use cases

• Deciding how many retries a client should make before giving up
• Checking a policy will not keep a user waiting for minutes
• Documenting what a service's retry behaviour actually is
• Producing fixture data for tests that assert on retry timing
• Explaining why a cap or jitter is needed, with real numbers

How this generator works

Each attempt's nominal delay comes from the strategy and the attempt number: exponential is base × 2^(n−2), linear is base × (n−1), Fibonacci scales the sequence, and fixed is the base throughout. The cap is applied to the nominal value, then jitter is applied to what remains, so a capped delay still jitters around the cap. The elapsed column is the running sum of everything before it, and the total is the sum of the whole column — so the figures always agree with the table rather than being computed separately.

Randomness and fairness

With jitter at zero the schedule is pure arithmetic and two runs produce identical output. Jitter is the only random element, and a seed replaces the cryptographic source with a small generator that is deterministic, not cryptographic — exactly what a committed fixture wants, and never something to derive a real delay from in production security code.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

• This is the client's schedule in isolation. It does not model the server, the failure, or how many clients are retrying at once — and the interaction between those is usually the real problem.
• Time spent on the request itself is not counted, only the waiting between attempts. A slow timeout can dominate the real elapsed time.
• Jitter is drawn from a flat distribution around the nominal delay. Full jitter — a uniform draw between zero and the delay — is a different and often better strategy that this tool does not model.
• There is no notion of which errors should be retried. Retrying a 400 forever is a common and expensive bug that no schedule can fix.

Common mistakes

Using exponential backoff with no cap

Ten attempts from one second is over eight minutes. Set a cap, or the last retries arrive long after the user has left.

Leaving jitter at zero

Every client that failed together retries together, and the recovering service is knocked over again. Even 25% jitter breaks up the synchronisation.

Counting the first attempt as a retry

Six attempts is five waits. The table shows the first attempt waiting zero for exactly this reason.

Practical tips

• Decide the total time budget first, then choose the attempts and cap that fit inside it — that is the constraint users actually feel.
• Compare the same base delay across strategies; the difference between exponential and Fibonacci at attempt eight is usually larger than expected.

Privacy and your data

Only numbers are entered and everything is computed in your browser. Nothing is uploaded, stored or written into the page address. Analytics records how many attempts were in the schedule and nothing else.

Frequently asked questions

What is exponential backoff?

Each retry waits twice as long as the last, so the load on a struggling service falls away quickly.

Why does jitter matter?

Without it, all the clients that failed at the same moment retry at the same moment. Jitter spreads them out so the recovering service is not hit by a synchronised wave.

Should I cap the delay?

Almost always. Without a cap the later waits become minutes, and a response nobody is still waiting for is not worth having.