Reconnect Backoff Visualizer — Free JS Snippet

When a WebSocket drops or an API call fails, the obvious naive fix is to retry every second on a fixed timer. That works fine for one client. It falls apart the moment a server goes down and every one of its thousands of connected clients starts hammering it at the exact same fixed interval the instant it comes back up, often taking it straight back down again — a pattern with a real name, the "thundering herd" problem. This snippet visualizes the standard production fix: exponential backoff with jitter, the same strategy used by AWS SDKs, gRPC clients, and every serious WebSocket reconnection library. A status indicator, a "Simulate Disconnect" trigger, and an animated per-attempt timeline make the otherwise-invisible retry math visible in real time.

Why fixed-interval retry is actively harmful

A server that is struggling — overloaded, restarting, or behind a saturated network link — needs load to *decrease* while it recovers, not to receive a constant, unrelenting stream of retry requests from every disconnected client at once. Fixed-interval retrying does the opposite: it applies steady, undiminished pressure exactly while the system is least able to absorb it. Worse, if many clients disconnected at roughly the same moment (a deploy, a network blip, a load balancer restart), fixed intervals mean they will all retry in near-perfect sync forever, since nothing in the algorithm ever spreads them apart.

The exponential part: computeDelay()

computeDelay(attemptIndex) computes BASE_DELAY * MULTIPLIER ** attemptIndex, clamped to MAX_DELAY with Math.min. With BASE_DELAY = 1000 and MULTIPLIER = 2, the capped wait sequence is 1s, 2s, 4s, 8s, 16s, 16s, 16s… — each failure roughly doubles how long the client waits before trying again, so a genuinely down server sees retry pressure fall off rapidly instead of staying constant. The MAX_DELAY cap exists so the wait does not grow unbounded forever; without it, a client that has been retrying for an hour would end up waiting increasingly absurd amounts of time between attempts, which is just as unhelpful as retrying too often.

The jitter part: why 0-300ms of randomness matters more than the doubling

On top of the exponential base, computeDelay() adds Math.random() * JITTER_MAX milliseconds. This is the detail that actually solves the thundering herd problem — exponential backoff alone does not. If ten thousand clients disconnect from the same outage at the same second, pure exponential backoff (no jitter) means all ten thousand retry at exactly 1s, then all retry again at exactly 3s, then all at exactly 7s, forever perfectly synchronized. Adding a random jitter component spreads each client's retry moment across a window instead of a single instant, so the server sees a smoothed trickle of reconnection attempts rather than repeated synchronized spikes. The visualizer's log deliberately prints the jitter contribution on every line (e.g. "jitter 47ms") so this normally-invisible randomness is visibly proven, not just claimed — running the simulation twice never produces identical wait times.

Animating the wait without blocking the UI

Each attempt's countdown is driven by animateWait(), an async function wrapping a requestAnimationFrame loop that computes elapsed time against performance.now() and resolves its promise once the duration has passed. The main sequence function, runBackoffSequence(), is itself async and simply awaits each wait, then a short simulated "connection attempt pulse" delay, then decides the outcome — reading as a clean, linear sequence of steps despite being entirely non-blocking and interruptible at any point via the running flag.

Deciding success: random chance vs. a deterministic test control

decideOutcome() supports two modes tied to the "Succeed on attempt" dropdown. In deterministic mode, a specific attempt number is chosen up front and the sequence succeeds exactly on or after that attempt — essential for demos, screenshots, and tests where a random outcome would be unreproducible. In random mode, the success chance is deliberately *not* fixed: it grows with each attempt (0.15 + attemptIndex * 0.18, capped at 90%), simulating a server that is gradually recovering rather than one that is either permanently broken or fixed on a coin flip — a small touch that makes the random mode feel like a real outage curve rather than arbitrary noise.

Why the status dot has three states, not two

The connection indicator cycles through three distinct visual states rather than a simple connected/disconnected toggle: solid green (connected), solid red (disconnected, no attempt in flight), and pulsing amber (reconnecting, actively counting down or attempting). That middle "reconnecting" state matters because a user watching a real app benefits from knowing a retry is actively in progress versus the app having simply given up — the pulsing amber animation (a CSS opacity keyframe) is the one piece of motion that runs continuously for the whole backoff sequence, independent of the per-attempt progress bar underneath it.