Welcome to the Alertpocalypse
Some jobs come with perks. Bonus schemes, remote work, the odd team lunch.
Mine has all of that, with the added bonus of a pager and the promise that if anything breaks I’ll be the first to know. One of my colleagues this week had that dubious pleasure, but they were pinged so many times their head was spinning.
Ping, ring-a-ding-ling
Let me set the scene. One of my colleagues got paged 60 times in a single week. Not a dramatic exaggeration. Not a fish-that-got-away story. A real human being was yanked from whatever fragment of rest or reality they were clinging to, once every few hours, by a stack of alerts that had the sensitivity of a toddler with separation anxiety.
and 20 of those came in over the weekend. You know, when you’re supposed to decompress, maybe touch grass, or at the very least, not be a living uptime insurance policy.
All Pain, No Gain
Now, here’s what happened next:
Nothing.
They didn’t get a day off. They didn’t get a thank-you. They didn’t get an incident review. They got a shout out at the company presentation, and that was it.
The deep dive into why we’re torturing our ops team with the reliability equivalent of a drunk smoke detector was unfortunately missing.
Which meant we didn’t set out to fix the root cause. So the next poor soul who moves into the on call firing line will experience the same horrendous experience. Welcome to the circular life of the on call developer, because the pressure never ends then even when you’re sleeping.
Tech Has a Memory Problem
You’d think someone, somewhere in this broken CI/CD chain of command might say:
“Hey, this isn’t normal. Should we… fix it?”
But no. Because in modern software development, the only thing shorter than sprint cycles is our collective memory.
Teams have started to treat on-call hell like weather. “It was a bad week for us”. “It’s been stormy lately”. It’s only ever us when it’s (well) you. That’s the way it is.
On-Call is a Systemic Failure
If you’re designing your system such that your engineers are being woken up at night multiple times a day, your system is broken. And if your company doesn’t stop the world to address it, your culture is broken too.
This isn’t resilience. It’s neglect.
Let’s get this straight: on-call isn’t supposed to be a punishment. It’s supposed to be the final defense in an emergency. If it’s happening daily, it’s not an emergency. It’s business as usual, and you’re treating your team like cheap batteries. Drain, discard, repeat.
The Price of Pretending
I don’t know what’s worse: the burnout, or the gaslighting. Because when people raise these concerns, they’re met with shrugs.
• “That’s just the way things are.”
• “It’s a learning opportunity.”
• “We’ll improve that next quarter.”
I think when we lose engineers and they mention on-call (obviously not in an exit interview, as we don’t have those) I wonder what management thinks and feels. We then take on another member of the on call clan and start the process again.
There’s this sick idea floating around in some leadership circles that paging your team constantly is a test of grit. Like you’re earning your stripes by sleeping with your laptop on your pillow. That’s not heroic. That’s medieval.
Conclusion
If you want to know how a company really treats its engineers, don’t ask about perks. Ask how they handle on-call.
• Do they give you time to fix what’s broken?
• Do they reward stability?
• Do they actually believe in work-life balance?
Or do they just want warm bodies and 99.99% uptime, no matter the cost?
Because every alert you ignore is a future resignation letter you just haven’t opened yet.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer worries that automation is simply another way to wake them up at 3am. Although that doesn’t matter that much as the existinal dread does that too.