The Stage Manager's Whisper: On Cues You Never See

I was backstage once, during a performance that felt, from the audience, like pure magic. What struck me wasn't the actors or the lights, but the stage manager in her black clothes, standing in the wings with a headset and a dimly lit script. Her world was a parallel one, built not on the performance itself, but on the architecture of cues. She marked the precise second a light should fade, the exact footfall that signaled a prop hand-off, the intake of breath before a sound cue. She called these moments, softly and constantly, into the void of her microphone. Most were never heard by the audience, and many weren’t even noticed by the cast. The show’s reliability depended entirely on this unseen, rhythmic calling of things about to happen.

It occurred to me later that this is the exact posture we should adopt for our small services. We spend so much time looking at alerts—the equivalent of a missed cue, a spotlight hitting an empty stage. But the real art, the stage manager’s art, is in the calling of the expected cue. It’s the log line that says “database connection pool refreshed at 04:00,” not because it failed, but because it succeeded. It’s the metric that ticks over when the nightly backup job starts, not just when it finishes or fails. It’s the quiet, scripted whisper in the wings that confirms the world is still following the script.

The Cue Light in the Dark

In theatre, they have ‘cue lights’—small, discreet LEDs that shine green or red to signal technicians out of earshot. A green light doesn’t mean “go,” it means “stand by; your cue is imminent.” The action happens on the red-to-green transition. Our systems need more cue lights. A cron job that has a health check endpoint which returns “204 No Content” when idle, and “200 OK” when it is actively running its task. A monitor that doesn’t just check if a process is alive, but checks if it has performed its core function in the last expected interval. These are the green lights going on in the darkness of the server rack, telling us the next beat is prepared.

The stage manager’s script is also a masterpiece of annotated reality. It doesn’t just contain the lines; it has notes on every prop, every light shift, every strange noise from the previous Wednesday’s show. Our runbooks should aspire to this. Not just “how to restart the service,” but “the service tends to lag after this specific upstream API call on rainy days; the cue to check is the 95th percentile latency graph, not the error rate.” It’s operational memory encoded not as a post-mortem, but as a marginal note for the next performance.

Finally, the most profound lesson is in the definition of a show’s “stop.” For the audience, it’s the curtain call. For the stage manager, the show isn’t over until every prop is reset, every ghost light is plugged in on the empty stage, and the theatre is locked. Our “stop” is similarly extended. A deployment isn’t done when the new code is live. It’s done when the first expected log line from the new version has appeared, when the error rate has settled back to baseline, when the old instances have drained and terminated cleanly. It’s the cue after the curtain, the work that makes the next performance possible.

We often think of reliability as building sturdy sets that won’t collapse. That’s part of it. But true, boring reliability is the work of the person in the shadows, whispering the sequence of the world into being, one confirmed, mundane cue at a time. It is less about holding the roof up, and more about knowing, with certainty, that it will.

Notes & further reading

A few pages I came back to while writing this: