Visualize Your Retry Backoff Schedule Before It Hits Production

Each retry attempt n (0-indexed) gets a nominal delay from the chosen strategy. Exponential uses base × multipliern, linear uses base × (n + 1), and fixed always returns base. Every nominal delay is then clamped to the cap: d = min(cap, nominal). This is the classic capped-exponential-backoff rule used by AWS SDKs, Google Cloud clients, and most message brokers.

Jitter breaks up the "thundering herd" problem, where thousands of clients that failed at the same instant all retry in lockstep and hammer a recovering server. Full jitter replaces the delay with a uniform random value in [0, d]. Equal jitter keeps half the delay fixed and randomizes the other half: d/2 + rand(0, d/2). Decorrelated jitter — the strategy AWS recommends for the best spread — ignores the plain exponential and instead computes sleep = min(cap, rand(base, prev × 3)), feeding each attempt from the previous one so the sequence self-decorrelates. None leaves the deterministic capped delay untouched.

The visualizer accumulates every actual delay into a running total. That cumulative figure is the real answer developers need: the total retry window, i.e. how long a failing payload survives in the queue before it is exhausted and dead-lettered. If your cap or attempt count pushes that window past your consumer's visibility timeout or the downstream's SLA, you will silently drop or duplicate events. Watching the timeline bar chart makes it obvious when the schedule flattens out at the cap and whether adding attempts still buys meaningful time or just wastes queue depth. Re-roll the jitter a few times to see the spread of realistic windows rather than a single deterministic guess.