Circuit Breaker Simulator

Tune the thresholds and see how many caller-seconds a breaker saves — and when a long open window makes a short outage worse.

How long the upstream is brokenThe one control. Take it below the open window and the breaker starts costing you more than it saves.

18 s

Outage starts atseconds into the 60s window

Failures before it opensconsecutive failed calls

Open windowseconds it rejects everything before probing again

Successful probes to closeconsecutive successes while half-open

Request raterequests per second, constant

Timeout on a failing callhow long one bad call blocks the caller

Caller-seconds spent blocked on a failing upstream

18 s

Without a breaker the same 60 seconds costs 1,080 s — 60.0× more waiting.

Breaker state second by second. Green closed, red open and rejecting, amber half-open and probing. The grey bar underneath is when the upstream was actually broken.

Calls that reached the upstream: 802
Calls the breaker never made: 398
Slow failures (waited for the timeout): 6
Fast failures (rejected instantly): 398
Failed requests, with the breaker: 404
Failed requests, without one: 360
Requests rejected after the upstream recovered: 2.20 s of them
Successful requests: 796

What this assumes: the upstream is binary — perfectly healthy or failing every call — and traffic arrives at a constant rate. Real degradations are partial, which is the case a consecutive-failure threshold handles worst: at a 40% failure rate a threshold of 5 may never trip at all. Every failing call costs the full timeout; every rejection while open costs nothing. The half-open state here lets each arriving request probe rather than admitting one and holding the rest, so recovery looks slightly faster than a strict single-probe implementation.

A circuit breaker does not reduce failures. Look at the two failed- request rows: with the breaker the total is usually higher, because while it is open it rejects traffic the upstream might have served. What it changes is the kind of failure. Without one, every request during an outage holds a connection, a thread and a caller for the full timeout; with one, the first few do and the rest are refused in microseconds. The headline is that difference, and at any realistic request rate it is the difference between a degraded dependency and a service that has run out of workers.

The setting that most people get wrong is the open window, and the slider is there to show it. Drag the outage down to two or three seconds while leaving a ten-second open window in place: the breaker trips, the upstream recovers almost immediately, and the tool then reports several seconds of requests rejected against a healthy dependency. A breaker tuned for a long outage makes short blips worse. If your dependency mostly has blips, a short open window with exponential growth on repeat trips is the shape you want.

Left out: partial failure, per-endpoint breakers, and what the caller does with the rejection. A breaker is only half a design — the other half is the fallback the fast failure allows you to run, which is the whole reason fast failure is better than slow failure in the first place.

Circuit Breaker Simulator

The reasoning behind this

Related tools