On-call burnout is no longer a fringe complaint. It is one of the loudest signals in the 2026 reliability data. A wave of fresh industry research this year points to the same uncomfortable conclusion: the people who keep systems running are running on empty. In the DuploCloud 2026 AI and DevOps Report, 47 percent of engineers said DevOps overload contributes to burnout, with on-call rotations and repetitive maintenance singled out as primary culprits. A separate study of 258 software engineers found that 83 percent reported burnout from DevOps overload. The Harness State of DevOps Modernization Report 2026, based on 700 practitioners and managers across five countries, found that a majority believe their current ways of working will not be sustainable over the long term.
If you lead an engineering team, that is your retention risk, your reliability risk, and your hiring cost, all wrapped into one metric you probably do not track closely enough. This post breaks down why on-call burnout is spiking in 2026, what the data actually says, and the practical steps you can take to reduce it without sacrificing uptime. The good news is that most of the fixes are process and tooling changes you can start this quarter, not a headcount request you have to defend for six months.
Burnout among on-call engineers is not new, but the 2026 numbers show it accelerating. Several forces are compounding at once, and understanding them is the first step to fixing the problem rather than papering over it with another wellness webinar.
Modern systems emit more telemetry than any human can reasonably parse. Every new microservice, third party dependency, and observability integration adds another stream of potential alerts. The result is a steady rise in pages that do not actually require action. When an engineer is woken at 3am for something that could have waited until morning, or worse, for something that resolved itself, the cost is not just a lost night of sleep. It is an erosion of trust in the alerting system itself. Over time, teams start ignoring pages, which is exactly how real incidents slip through.
The DuploCloud research found that nearly 30 percent of engineers lose a third of their week to repetitive infrastructure tasks and audits. A meaningful chunk of that time is spent triaging noise: acknowledging alerts, checking dashboards, and confirming that nothing is actually wrong. That is cognitive load with no reliability payoff.
One of the more striking findings from the Harness report is that pressure is highest among the heaviest users of AI coding tools. Among very frequent users of AI assistants, 81 percent said their current ways of working will not be sustainable. Faster code generation means faster deployment, more frequent change, and a larger surface area for things to break. If your team is shipping more often but your incident response process has not evolved to match, the on-call engineer absorbs the difference. Velocity at the top of the pipeline becomes stress at the bottom.
Most engineering teams are not large enough to staff a true follow the sun rotation across time zones. That means a small group of people carries the pager, often the same senior engineers who are also expected to lead projects, mentor juniors, and attend a full day of meetings. When the same names appear on every escalation, the load concentrates instead of distributing. Burnout is rarely about a single bad night. It is about the accumulation of many nights where recovery never fully happens.
It is tempting to treat burnout as a soft problem, something HR handles with a survey and a gym stipend. The 2026 data makes clear that it is a hard operational risk with measurable consequences.
Start with reliability. A tired engineer makes worse decisions during an incident. Mean time to resolution stretches when the responder is exhausted, unfamiliar with the failing service, or demoralized enough to do the minimum. Every extra minute of downtime has a dollar figure attached, and burnout quietly inflates that figure across every incident your team handles.
Then consider attrition. Replacing a senior site reliability engineer is expensive and slow. When your most experienced responders leave, they take institutional knowledge with them: the undocumented runbook in their head, the intuition about which dashboard to check first, the memory of the last three times this exact failure happened. That knowledge loss makes the next incident harder for everyone who remains, which accelerates their burnout in turn. It is a doom loop, and it starts quietly.
There is also a communication cost that often goes unmeasured. When responders are stretched thin, incident communication suffers. Status pages go stale, stakeholders are left guessing, and customers lose confidence. The recurring pattern of companies going silent during outages this year, where public threads move from "under investigation" to "fixed" with no explanation in between, is often downstream of a response team that simply does not have the bandwidth to communicate well while also fighting the fire. Reporting on the 2026 pattern of quiet status pages shows how quickly transparency erodes when teams are overwhelmed.
The encouraging part of the 2026 research is that the biggest sources of burnout are also the most fixable. They are process and tooling problems, not immutable facts of engineering life. Here is where to focus.
The single highest leverage move for most teams is reducing the volume of low value pages. Every alert should answer one question: does a human need to act right now? If the answer is no, it should not page. It can log, it can open a ticket for business hours, or it can be suppressed entirely. Auditing your alert rules against real incident history usually reveals that a small number of noisy alerts generate the majority of interruptions.
Practical tactics that consistently reduce noise include:
Burnout concentrates when the same people carry the pager repeatedly. Fair, transparent scheduling spreads the load and makes the burden visible. Rotations should be predictable enough that engineers can plan their lives around them, and flexible enough that swapping a shift for a doctor's appointment or a family event does not require a manager's intervention and three Slack threads.
Overrides and shift swaps should be self service. When an engineer needs coverage, the friction of arranging it should be near zero. The harder it is to hand off the pager, the more people white knuckle through shifts they should have swapped, which is exactly the kind of grind that produces resentment and exits.
Speed matters, but so does the experience of responding. An engineer who gets paged into a well organized incident, with the right context automatically attached and the right people already looped in, has a fundamentally different night than one who gets a cryptic alert and has to assemble the response from scratch. Reducing the cognitive tax of each incident is a direct investment in your responders' wellbeing.
That means automating the boring parts: creating the incident channel, pulling in the relevant service owners, attaching recent deploys and dashboards, and starting a timeline automatically so the postmortem writes half of itself. Every manual step you remove is one less thing a stressed responder has to remember at the worst possible moment.
Most engineering teams already live in Slack. That is where questions get asked, where deploys get announced, and where the informal coordination during an incident actually happens. The problem is that traditional on-call tooling often lives somewhere else, forcing responders to context switch between a paging app, a ticketing system, a video call, and the Slack channel where the real conversation is happening. Every switch adds friction, and friction at 3am is exactly what you do not want.
This is the case for a Slack-native approach to on-call and incident management. Tools like Pagerly are built so that the rotation, the paging, the escalation, and the incident coordination all happen inside Slack, where your team already works. That design choice matters for burnout in a few concrete ways.
None of this is about replacing engineering judgment with automation. It is about removing the repetitive, avoidable friction that the 2026 research repeatedly identifies as a burnout driver. The goal is to let responders spend their energy on the genuinely hard parts of an incident, not on the plumbing around it.
You do not need a reorg to make progress. Here is a sequence any team can run over a single month to move the needle on on-call burnout.
You cannot fix what you do not measure. Pull the data on how many pages your team received in the last quarter, what time they arrived, how many happened outside business hours, and how many required actual action versus self resolved. Look at the distribution across people, not just the total. If two names account for most of the after hours pages, you have found your first problem.
Rank your alerts by volume and by action rate. The alerts that fire often but rarely lead to action are your best candidates for tuning, downgrading, or deletion. Aim to cut total page volume by a meaningful percentage in a single focused session. This is usually the fastest visible win, and it builds momentum for the harder changes.
Rebalance the rotation so the load is distributed fairly. Set up self service overrides and shift swaps so handoffs are effortless. Make the schedule visible to the whole team. If your tooling makes any of this hard, that is a signal to consider a more integrated, Slack-native setup.
Automate incident creation, channel setup, and stakeholder notification. Write or update the runbooks for your most common incidents so a tired responder is not reconstructing the fix from memory. Establish a lightweight, blameless postmortem habit so every incident makes the next one easier instead of just adding to the pile.
Tooling and process get you most of the way, but culture determines whether the improvements stick. A few principles separate teams that manage on-call sustainably from teams that burn through their best engineers.
Treat on-call as real work, not an invisible tax. Time spent responding to incidents overnight is time that should be acknowledged, compensated where appropriate, and recovered from. An engineer who was up at 3am should not be expected to deliver a full day of feature work the next morning as if nothing happened.
Make blameless postmortems non negotiable. When something breaks, the question is what in the system allowed it, not who to blame. Blame drives silence, silence drives repeated failures, and repeated failures drive burnout. The teams that publish honest, blameless postmortems learn faster and page less over time.
Give responders authority to match their responsibility. Nothing is more demoralizing than being accountable for uptime while lacking the power to fix the underlying problems. If your on-call engineers keep getting paged for the same issue, they need a real path to eliminate it, not just to keep acknowledging it.
Finally, listen to the signal your own data is sending. The 2026 reports are not describing some other industry. If your engineers are quietly telling you the pace is unsustainable, believe them before the attrition numbers force you to.
The 2026 data is a warning, but it is also an opportunity. On-call burnout is spiking because alert volume, deployment velocity, and thin rotations are compounding faster than most teams have adapted their processes. The teams that treat this as an operational problem, and attack it with better alerting, fairer scheduling, calmer incident response, and a culture that respects responders, will not just retain their best engineers. They will run more reliable systems, because rested and supported responders resolve incidents faster and communicate better while doing it.
You do not have to solve everything at once. Start by measuring your real on-call load, cut the noisiest alerts, and make sure the burden is fairly distributed and easy to hand off. A Slack-native tool like Pagerly can make each of those steps easier by keeping on-call, paging, and incident coordination in the place your team already works. Reliability and engineer wellbeing are not competing priorities. In 2026, they are the same priority, and the sooner you treat them that way, the healthier both your systems and your team will be.
