On-Call Engineering: Cut Burnout Without Hurting Reliability
On-call engineering doesn't have to mean choosing between team burnout and system reliability. This article explores four practical strategies that protect both your engineers and your uptime, backed by insights from experienced engineering leaders. Learn how small changes to your on-call process can reduce stress while maintaining the high availability your customers depend on.
Offer a Next Week Recovery Day
One thing I've learned over the years is that maintaining reliable support isn't just about having someone available after hours; it's about making sure the people providing that support feel valued and supported as well.
At GO Technology Group, we created an on-call rotation to provide emergency response and after-hours support for our managed IT services clients. One change that made a lasting difference was giving technicians an additional day off during the following week after serving on call. When someone spends a week carrying that extra responsibility, we want them to have time to recharge.
The result has been consistently positive. Our team stays engaged with the process, and technicians are more likely to bring the positive attitude and energy our clients expect when issues arise. I've found that people are willing to go the extra mile when they know their effort is recognized. For us, that balance has helped maintain both strong service reliability and a healthy team culture, which ultimately benefits the organizations that rely on our IT support services every day.
Page Only for Critical Incidents
I stopped treating every alert as equally urgent , I split alerts into "wake you up at night" and "fix it tomorrow morning" categories.
Before this change, engineers were getting paged at 2am for things that honestly could wait until morning. Many were tired and making mistakes, and some were looking for other jobs. The following changes were made to improve the situation.
1- The team reviewed every alert. Management and employees asked if paging for an alert was warranted or if people were just being paranoid.
2- Pager alerts would be split into two. Business critical alerts that page employees and prompt the urge to respond now. Less critical alerts do not page and are noted for response during business hours.
3- Each engineer's on-call time was limited to one week. Instead of paging for alerts, engineers spent the next two weeks uninterrupted and improving.
4- I made sure every on-call engineer had a backup , nobody handles incidents completely alone at midnight.
Since these changes, the team has improved and has been able to respond quickly to critical alerts. Instead of being drained and thinking of leaving, employees were less burned out.
my advice is to have fewer and more intelligent alerts, rather than a flood of alerts, are much more helpful.
Pause Features When Reliability Drops
I design our on-call rotation and alert policy around one core principle: treat stability as the product. Alerts and escalations prioritize customer-visible incidents, and spikes tied to recent changes, burning through the error budget, or rising change failure rate are the signals that shift priority from features to fixes. The one change that delivered sustained improvement was a firm rule to pause new feature rollouts whenever a release was spending trust faster than it was adding value. That rule made on-call work more predictable and let teams focus on restoring customer experience rather than repeatedly firefighting new changes.
Adopt a Paired First Responder Model
I run Paperless Pipeline, a real estate transaction SaaS, bootstrapped since 2009. We support 1,700+ brokerages and 90,000+ users on infrastructure that must stay up because brokerages depend on us at their closing tables. We have run engineering on-call across sixteen years and the one change that delivered sustained improvement was switching from a single primary on-call to a primary-and-shadow pair.
The setup before. One engineer on primary call for a week at a time, no shadow. Alerts fired, the primary responded. The problem was burnout, not because the alert volume was high (it was not), but because the on-call week was psychologically exhausting. The primary slept with the phone next to the bed, never went out without a laptop, and approached the end of the week genuinely depleted. We were losing engineers to roles at companies with no on-call rotation.
The change. We moved to primary-and-shadow pairs, also for a week at a time. The primary handles the page. The shadow is reachable as backup. If the primary needs to step away for an evening (dinner with family, a movie, a long run), the shadow takes pages for those hours, by arrangement. The shadow is not on a hot pager. They are simply the agreed-upon backstop the primary can lean on.
What changed. Two specific outcomes. One, engineers can plan their lives during their on-call week. Knowing there is a backstop reduces the psychological weight from "I cannot do anything" to "I am the first responder but I have help." Two, the shadow learns the system by watching the primary respond. Six months after we shipped the change, every engineer in the rotation was demonstrably more competent at incident response, because they had spent twice as many weeks adjacent to real incidents.
The alert policy that complements it. We brutally cut alert noise. The rule is "if it pages and we did not need to act, we kill the alert by end of day." About 40% of our original alerts disappeared in the first quarter under that rule. Sleep returned. Service reliability stayed exactly where it was.
