STITCH_CIRCUIT_OPEN

What you'll see

A stitch configured with a circuit fails immediately — no request leaves the process — with a StitchError surfaced on the event stream as an error event (phase circuit). The dependency itself isn't being hit: the breaker tripped open after repeated failures and is now fast-failing every call to protect it. This is the breaker doing its job, not a fresh failure.

Why it happens

The breaker counts consecutive failures. Once it reaches failureThreshold, it trips open and records the moment. While open, every call fast-fails for cooldownMs instead of touching the dependency. Seeing this error means you are inside that cooldown window — the breaker hasn't yet allowed the half-open trial that decides whether to close again. The real failures that tripped it happened on earlier calls; this one is just being short-circuited.

How to fix

Most of the time this is working as intended — a failing dependency is being shielded from a stampede. Work through these in order:

• Wait it out. After cooldownMs (or halfOpenAfterMs, if set) the breaker goes half-open and lets a single trial through; a success closes it and traffic resumes. If the dependency has recovered, the next call after the window will succeed.
• Fix the underlying dependency. The breaker is a symptom, not the cause. Find and fix the real failures — the earlier errors that incremented the count to failureThreshold — so the half-open trial can close it.
• Tune the thresholds. Raise failureThreshold if the breaker trips on transient blips; adjust cooldownMs / halfOpenAfterMs to control how long it fast-fails before retesting.
• Check the key. Breakers are keyed (default: the stitch/host key). If two unrelated stitches share a key, one failing dependency trips the breaker for both — give them distinct keys so they don't share a breaker.

Pair the breaker with retry and timeout: timeouts and retries absorb the transient failures, and the breaker steps in only once those keep failing.

Related