Output Suspended: the Circuit Breaker

What You're Seeing

When an output connection keeps failing, CueSync stops sending to it and suspends it — the output is reported as having its circuit breaker open. You'll see a Circuit Breakers Open banner on Network → Monitor, an N BLOCKED · RESET chip on Devices, a circuit-breaker badge on affected Cue Pads and an error notification — and the Diagnostics connection-event log and (if you use it) the Companion system monitor record it too. Cues routed to that output stop being sent until the connection recovers; every other output keeps running normally.

This is deliberate. A console that disappeared mid-show would otherwise hold up the outputs that are still healthy.

How CueSync Recovers

• Automatic checks — CueSync keeps checking the connection on its own. Once the output answers again, normal output resumes; if it doesn't, CueSync waits and checks again, and the reset chip below retries immediately.
• Quick restarts — a console whose software restarts quickly usually reconnects before the output is ever suspended.
• No replay of old commands — a cue that could not be delivered is reported, not held back and replayed after the output recovers, so a recovering console gets current show state, not a flood of old commands.

Bringing It Back Faster

1. Fix the actual failure first — cable, switch port, target software running, right IP. The Diagnostics Recent connection events log timestamps every disconnect and suspension, so you can see exactly when and how it died.
2. Click the N BLOCKED · RESET chip on Devices to reset every blocked output and reconnect it, or toggle a single output off and on in Network → Outputs — either retries immediately instead of waiting for the next automatic check.
3. If the output flaps (connects, then drops, repeatedly), Diagnostics flags it FLAPPING — the cause is almost always a cable, a duplicate IP address, or the target application repeatedly crashing.

During a Show

A suspended output is shown on screen and raises an error notification when it happens. Outputs sent over UDP cannot confirm delivery, so a healthy status there only shows the packet left CueSync. Everything else keeps running: the failing output is isolated so the rest of your rig doesn't stutter. If the output carries something critical (your main console), fix the link and watch for the recovery notification rather than restarting CueSync — a restart throws away the connection health history without reconnecting anything faster.