Backoff and Jitter Playground

When a server falls over, every client that was talking to it times out at roughly the same moment. If they all retry on the same schedule, they all come back at the same moment too.

This experiment computes retry delays for 24 simulated clients that failed simultaneously. The top strip shows plain exponential backoff; the bottom strip applies the jitter mode you choose. Each row is one client; each mark is one retry.

Base delay

200 ms

Multiplier

× 2

Cap

8.0 s

Retries

6

Jitter

NoneEqualFull

Draw new random delays

06.3 s13 s

One client's schedule with the current settings

Retry	Ceiling	Delay	Fires at
1	200 ms	2 ms	2 ms
2	400 ms	25 ms	27 ms
3	800 ms	782 ms	809 ms
4	1.6 s	1.1 s	1.9 s
5	3.2 s	1.7 s	3.6 s
6	6.4 s	2.6 s	6.2 s

The schedules

For retry number $n$ (counting from zero), with base delay $b$, multiplier $m$ and cap $c$, the exponential ceiling is

$$d_n = \min\left(c,\; b \cdot m^{\,n}\right).$$

The three modes then choose the actual delay as follows, where $U(a, z)$ is a uniformly random value between $a$ and $z$:

Mode	Delay before retry $n$
None	$d_n$
Equal	$d_n / 2 + U(0,\, d_n / 2)$
Full	$U(0,\, d_n)$

Without jitter, every client computes the same $d_n$, so the “most retries within” count equals the number of clients: each wave of retries arrives at once. Any randomness spreads them out; full jitter spreads them the most, at the cost of some clients retrying sooner than the ceiling.

Notes on the experiment

• Randomness comes from a seeded generator, so the server-rendered page and the interactive version agree, and “draw new random delays” is reproducible.
• The simulation is deliberately simple: it ignores request duration and whether retries succeed.
• Spreading retries out only helps if repeating a request is harmless — the subject of Idempotency, and Why Retries Need It.