The Stage Manager's Cue Light: On the Signal That Must Not Be Seen

The theatre’s blackout is absolute. In the wings, a dancer holds a breath, a stagehand’s hands hover over a rope. The silence is a held note. Then, a soft green glow from a tiny, shielded bulb on the wall. Not a sound. The cue is executed, the scenery flies in, the actor enters. The audience sees only the magic. The stage manager’s cue light—a simple, binary signal—is a masterpiece of operational reliability from a field far removed from our servers and scripts. It offers profound lessons for those of us running small, boringly essential services.

The Unseen Backchannel

In theatre, the headset chatter is constant, a river of technical details and adjustments. But for the critical, split-second action—the one that, if mistimed, causes a collision in the dark—they don’t shout "Go!" over a noisy channel. They use the light. It’s a dedicated, silent, unambiguous backchannel. In our systems, how often do we rely on a single, noisy stream (a chat log, a crowded dashboard) for our critical alerts? The cue light teaches us the value of a separate, minimal pathway for the signal that truly matters. It’s the heartbeat ping on a separate port from your application traffic; it’s the single-purpose healthcheck endpoint that returns nothing but 200 or 500, no parsing required.

More importantly, the cue light is patiently persistent. It doesn’t flash and vanish. It glows steadily, waiting. The stagehand watches for it, and only acts once it is definitively, continuously on. It avoids the race condition of a transient signal. Translated to our world: a healthcheck shouldn’t judge a system on a single, fleeting failure. It should look for sustained state over a sensible window, turning its light from red to green only when the condition is stable. This prevents the cascading chaos of services bouncing based on a momentary blip.

Finally, and perhaps most beautifully, the cue light is context-aware yet simple. That same green bulb means different things to different people—to Flyperson A it’s ‘lower the chandelier,’ to Actor B it’s ‘enter stage left.’ But the instruction itself is never embedded in the light. The complexity is distributed, handled in the preparation, the rehearsal, the shared understanding. The signal remains stupidly simple. Our monitoring alerts should aspire to this. Instead of an alarm screaming "POSTGRES_CONNECTION_POOL_EXHAUSTION_ERROR_CODE_57," we need a cue light that says "database unhappy." The interpretation—the runbook, the memory of last Tuesday’s fix—lives with the operator. The signal merely directs attention.

Running a reliable service is less about dazzling technology and more about creating conditions for flawless execution. It’s about designing the backstage so the show appears effortless. The stage manager, in the darkness, trusts a small, quiet light. They have rehearsed its meaning until it’s reflex. Our systems deserve the same: not more alerts, but clearer, more reliable, more thoughtful signals. The kind you act on without a second thought, because you’ve built a world where that single, steady glow tells you everything you need to know.

Notes & further reading

A few pages I came back to while writing this: