Backoff & Jitter Calculator

How It Works

Retries without jitter are how a transient blip becomes an outage. This works out the delay schedule for exponential backoff and shows how each jitter strategy spreads it across attempts. It only computes — it never retries anything.

The formula

Exponential backoff is delay = min(cap, base × factorⁿ⁻¹) for attempt n:

• base — the first wait (e.g. 100 ms).
• factor — the growth per attempt (2 doubles each time).
• cap — the ceiling, so the wait doesn’t grow unbounded. Without a cap, base 100ms × 2 reaches ~3.4 minutes by attempt 12.

Why jitter — the thundering herd

If a thousand clients back off on the same schedule, they retry in synchronized waves — the very spike that knocked the service over, repeated on a timer. Jitter desynchronizes them by randomizing the wait.

• Full — uniform in [0, delay]. Maximum spread; a client may retry very soon.
• Equal — uniform in [delay/2, delay]. Keeps a floor so nobody hammers instantly, still spreads the herd.
• Decorrelated — the next wait is uniform in [base, previous × 3], capped. It adapts to the last sleep and is a strong general default (AWS’s recommendation).
• None — the bare synchronized schedule. Fine for a single client; dangerous for a fleet.

Reading the table

Min/Max is the range a given attempt’s wait can fall into. For None, min equals max. The summary’s worst-case total wait sums the maximum of every attempt — the longest a client could wait in total before giving up after N tries. Watch how Full and Decorrelated pull that range down compared to None: that lowered floor is exactly the load you take off a recovering service.

A retry is also how the same message gets delivered twice, so the handler on the other end has to be idempotent: see the BabelQueue idempotency spec and the runnable idempotency-payments example.

Privacy

Everything runs in your browser. No inputs leave the page.