Circuit Breaker States
A circuit breaker cycles through three states: Closed (requests flow normally), Open (requests are blocked after failures), Half-Open (a few test requests check if the service recovered).
What is Circuit Breaker States?
In short
A circuit breaker is a fault-handling component that wraps calls to a remote service and moves between three states: Closed, where calls pass through and failures are counted; Open, where calls are rejected immediately for a cooldown period after too many failures; and Half-Open, where a small number of trial calls are allowed through to test whether the service has recovered, promoting the breaker back to Closed on success or back to Open on failure.
What the three states mean
A circuit breaker sits between a caller and a downstream dependency (an API, a database, a payment gateway). Instead of letting every request hammer a service that is already failing, it tracks the health of recent calls and changes behavior based on three states.
Closed is the normal, healthy state. Every request is allowed through to the downstream service. The breaker keeps a running tally of successes and failures. As long as failures stay under the threshold, it stays Closed.
Open is the tripped state. Once failures cross the configured threshold, the breaker flips to Open and stops sending traffic downstream. Calls fail instantly with an error or a fallback response, so the caller does not waste time waiting on timeouts. The breaker stays Open for a fixed cooldown window, often 5 to 60 seconds.
Half-Open is the recovery probe. When the cooldown expires, the breaker lets a small number of trial requests through. If those succeed, the service looks healthy again and the breaker returns to Closed. If any of them fail, it snaps back to Open and waits out another cooldown.
How the state transitions work under the hood
The Closed-to-Open transition is driven by a failure detector. Older designs trip after N consecutive failures (for example, 5 in a row). Modern libraries like Resilience4j use a sliding window: they look at the last 100 calls or the last 10 seconds and trip if the failure rate exceeds a percentage, such as 50 percent. Slow calls that exceed a latency limit can also count as failures.
The Open-to-Half-Open transition is purely time based. A timer starts when the breaker opens. When it expires, the breaker does not immediately resume full traffic. It moves to Half-Open and caps how many test calls it allows at once, often just one to ten.
The Half-Open transitions decide the verdict. A configured number of successful trial calls promotes the breaker to Closed and resets the failure counters. A single failure (or failures past a small threshold) demotes it back to Open. While in Half-Open, extra calls beyond the trial limit are usually rejected so a flood of traffic does not overwhelm a service that is still fragile.
State is held per dependency instance, not per request. The counters, the window, and the current state live in memory in the calling service, which is why each pod or process maintains its own breaker rather than a shared global one.
When to use it and the trade-offs
Use a circuit breaker on any synchronous network call to a dependency that can fail or slow down: a third-party API, a microservice, a cache, a database behind a connection pool. The core benefit is fail-fast behavior. Without it, a slow downstream service causes callers to pile up on timeouts, exhaust thread pools and connections, and drag down the whole system in a cascading failure.
The main trade-off is that an open breaker rejects requests that might have succeeded. During the Open state you are trading some availability for stability of the overall system. Pairing the breaker with a fallback (cached data, a default value, a degraded feature) softens this for the user.
Tuning is the hard part. Set the failure threshold too low and the breaker trips on normal blips, hurting availability. Set it too high and it never protects you. The cooldown also matters: too short and you keep slamming a recovering service, too long and you stay degraded after it is healthy. These values need to be tuned against real traffic and timeout settings.
One caveat: because state is per instance, a fleet of 50 pods has 50 independent breakers. They will not trip in lockstep, which is usually fine but means recovery probing is distributed rather than coordinated.
Where it is used in production
Netflix Hystrix
The library that popularized the pattern, wrapping every inter-service call at Netflix with per-dependency breakers and fallbacks before being put in maintenance mode.
Resilience4j
The modern Java standard that replaced Hystrix, using a count-based or time-based sliding window and exposing Closed, Open, and Half-Open as explicit configurable states.
Istio and Envoy
Implement breaker-style outlier detection at the service mesh layer, ejecting unhealthy upstream hosts so application code does not have to manage breakers itself.
Polly (.NET)
Provides circuit breaker policies for .NET services, with both consecutive-failure and advanced rate-based breakers that move through the same three states.
Frequently asked questions
- What is the difference between the Open and Half-Open states?
- Open rejects every call immediately during a cooldown window and sends no traffic downstream. Half-Open begins after the cooldown and lets a small, limited number of trial calls through to test whether the service recovered, then decides to close or re-open based on the result.
- How does a circuit breaker decide when to trip from Closed to Open?
- It watches recent calls. Simple breakers trip after a set number of consecutive failures. Modern ones use a sliding window over the last N calls or last few seconds and trip when the failure rate (and sometimes the slow-call rate) crosses a configured percentage like 50 percent.
- What happens to requests while the breaker is Open?
- They fail fast. The breaker returns an error or a fallback response without contacting the downstream service, so callers do not block on timeouts and connection or thread pools are not exhausted.
- Is the circuit breaker state shared across all instances of a service?
- No. State is held in memory per process or pod, so each instance maintains its own counters and breaker. A service running 20 replicas effectively has 20 independent breakers.
- How is a circuit breaker different from a retry?
- A retry re-attempts a single failed call hoping it succeeds. A circuit breaker tracks failure patterns over many calls and stops attempts entirely once a dependency looks unhealthy. They are often combined, but retrying through an open breaker would defeat its purpose, so retries should respect the breaker state.
Learn Circuit Breaker States hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
Retry
Automatically re-attempting a failed operation, usually with exponential backoff. Essential for handling transient failures in distributed systems.
Timeout
A maximum duration to wait for an operation to complete before giving up. Without timeouts, a stalled dependency can hang your entire system indefinitely.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.