Field Notes from the Stack: The Cost of On-Call

Week ending September 12, 2026

It's been a tough on-call week for my team and me. In fact, I started writing this after working on an alert that came in at 8 PM on a Friday.

I'm fortunate enough to be able to think about on-call as both an individual contributor and as an engineering leader. I can see how similar the burden is even though many ICs I've worked with often saw leadership as a means to escape the pager. I see some of my EM peers, or members of their teams, who have never been on an operational team and don't understand the frustration of writing a messy break-fix to keep the lights on. Or perhaps it's that product manager wondering why some feature work slows to a crawl or why an engineer might be short with someone during a retro call.

Being on an on-call rotation creates some amount of stress, some type of worry or concern, whether it's for the primary on-call, the leader who is the escalation point, or that secondary on-call engineer who only gets paged once a quarter. Even those only tangentially related to an on-call rotation might have some stress. Maybe that TPM is getting a lot of grief on why a certain service is unreliable from the sales team.

How do you deal with everything being on fire and never seeming to get better? What are some strategies you can implement on your own or encourage others to use?

Even the most experienced on-call engineer needs a strong support network, and that starts with their team and their leader. It really just boils down to a couple of things.

If you're an individual contributor who's on-call, don't be afraid to ask for help or just tell the truth when asked how you're doing or when reporting your status in standup. "Hey, I have to investigate the primary DB cluster because its CPU is spiking and the app is dragging; can someone take a look at the WAF for me to make sure it's not a DoS?"

For the IC that's not holding the pager, keep an eye on the on-call engineer. Make sure they're doing well. Check in. Make sure they're not carrying the burden of your 800 microservices alone. Ask if there's anything you can take on or help with. Not every on-call engineer feels comfortable delegating, or they may feel it's a sign of a weak engineer to ask for help. If you're a senior engineer, like a staff or principal engineer, lead by example. Show them that it's okay to delegate, ask for a second set of eyes, or do a sanity check.

If you're a leader, check in and make sure that engineer is doing well. You should have a sense of the on-call load. Is it reasonable for one engineer, or do you need a different strategy? Maybe a different schedule split or a week for the whole team to swarm on some of the more chronically broken services. How many times was your engineer woken up this week? How long were they awake? Did they work from 1:30 to 4:30 in the morning, and then you got on their case about why they weren't at standup at 9 in the morning? As a leader, you're responsible for setting that culture and building a space where on-call engineers can be effective without burning out.

One of the most important concepts for a leader is remembering that on-call is an extra burden that rarely stays within business hours. If your on-call engineer worked late into the evening on an issue, let them miss standup and start a few hours later to get some rest.

A good way to gauge the on-call load is to take a week for yourself. It helps you understand what your team is dealing with, keeps you close to the noise, and builds esprit de corps.

Of course, it's not all bad. When it's quiet, on-call can be relaxing; you can work on projects or tech debt that has been idling in the backlog. You can sit down and work on those runbooks and automations that you've been putting off for months. But in my experience, if it's quiet, then something is probably just silently broken.