Most on-call rotations start with good intentions and end with someone updating their LinkedIn. The schedule ships as a shared Google Sheet, the team agrees to weekly handoffs, and for the first month things feel manageable. Then the 3 AM pages start compounding. Alert noise grows. The engineer on rotation spends their weekdays recovering from their nights, and the backlog doesn't care.
On-call engineer burnout is not a character flaw. It's a structural problem, and structural problems respond to structural fixes.
What makes on-call rotations unsustainable
The most common failure isn't the volume of incidents. It's the volume of noise that doesn't lead to incidents. A PagerDuty study found that operations teams spend roughly 30% of their time on unplanned work, and a large portion of that time goes to triaging alerts that require no action. When every alert feels urgent and most turn out to be nothing, the person holding the pager stops trusting the system.
Three patterns show up in almost every team that struggles with on-call:
Rotation pools are too small. A four-person team on weekly rotation means each engineer carries the pager 13 weeks a year. That's a quarter of every year spent sleeping lightly, checking Slack during dinner, and mentally rehearsing runbooks. Anything under six people in the rotation creates a cadence that wears through even the most willing volunteers.
Alerts lack severity context. When a staging environment flapping at 2 AM triggers the same notification as a production database going offline, engineers learn to treat all pages the same way: with dread first, then with indifference. Without clear incident severity levels, the on-call engineer becomes a human priority sorter, doing work that a well-configured system should handle automatically.
Recovery time doesn't exist in the schedule. The engineer finishes a rough on-call week and is expected to hit sprint velocity on Monday morning. There is no decompression built into the rotation, no acknowledgment that interrupted sleep for seven nights has a cognitive cost that doesn't reset with a weekend.
Reducing alert noise before it reaches a person
The fastest way to improve on-call quality is to reduce the number of alerts that wake someone up. Not by suppressing them, but by routing them correctly.
Start with an audit. Pull every alert that fired in the past 30 days and categorize each one: did it require human action within an hour? If the answer is no, it should not page. It might still warrant a Slack message or a ticket for morning review, but it should not vibrate someone's phone at 3 AM.
Severity-based routing is the mechanism that makes this practical. A warning-level check failure goes to a dashboard. A critical failure goes to the on-call channel. A P0 pages immediately. Most monitoring alert setups support this kind of tiered routing, but teams rarely configure it because the default path of "send everything to the same channel" works fine when you have five monitors. At fifty, it creates a firehose.
Resource grouping helps too. If your checkout service has twelve monitors across HTTP health, DNS, SSL, and API latency, group them so that a cascading failure produces one consolidated alert instead of twelve independent pages. The on-call engineer doesn't need to know that all twelve fired. They need to know that checkout is down.
Designing rotations that people can live with
Rotation structure has more impact on burnout than most teams realize. The defaults feel obvious (weekly rotation, alphabetical order), but small adjustments compound over months.
Longer rotations, less often. A two-week rotation with a full recovery week afterward is often less draining than weekly swaps. The weekly handoff creates a constant context-switch cost, and the engineer never fully settles into the role before passing it along. Two weeks gives enough time to develop familiarity with the current state of the system. For more on rotation structure, see the on-call rotation best practices guide.
Follow-the-sun where possible. If your team spans time zones, route pages to whoever is awake. Overnight pages are the single largest contributor to burnout, and even partial coverage (handling pages until midnight local time instead of through the full night) makes a meaningful difference. An engineer in Berlin shouldn't get paged at 4 AM when a colleague in San Francisco is eating lunch.
Define an escalation path. The on-call engineer should never feel alone. If they can't resolve an issue within a defined window, escalation to a secondary responder should be automatic. Knowing that backup exists, and that escalation is expected rather than a sign of failure, changes how people experience on-call entirely.
Compensation and recognition
On-call is real work. It costs real things: sleep, personal time, cognitive capacity the next day. If your organization doesn't compensate for it, the people who can leave will leave, and the rotation pool shrinks, which accelerates burnout for everyone remaining.
Compensation takes different shapes depending on the company. Some teams pay a flat weekly stipend for carrying the pager. Others add per-incident bonuses. A few give compensatory time off after high-severity weeks. The specific model matters less than the principle: on-call should never be invisible, unpaid labor.
Beyond money, recognition matters. Teams that review on-call load in retrospectives, that track MTTR and use it to justify investing in better tooling, and that treat operational work as a first-class contribution in performance reviews tend to retain their on-call engineers longer.
Automation as a pressure valve
Every alert that a human triages is an opportunity for automation. Not every alert can be automated, but many can be.
The Google SRE Workbook recommends tying alerts to SLO burn rates rather than raw threshold violations. A single failed health check is noise. A pattern of failures that puts the error budget at risk is signal. This distinction, applied consistently, can cut actionable pages by half or more.
Automated runbooks handle the next layer. When a known failure pattern triggers a page, the system executes the first response steps (restart the service, drain the node, scale the pool) and only escalates if the automated fix doesn't resolve within the expected window. The on-call engineer's role shifts from "human monitoring system" to "decision-maker for the edge cases automation couldn't handle." That's a role people can sustain for years, not months.
The rotation you'd actually volunteer for
Sustainable on-call comes from building systems where the pager interrupts less often, the interruptions are worth responding to, and the people carrying the load are compensated fairly.
Start with the alert audit. Fix routing and severity filtering so that only actionable problems reach the on-call phone. Expand the rotation pool if it's under six people. Add recovery time to the schedule. Pay people for the work they're doing outside business hours. Automate the patterns that repeat.
If you're working on the routing and filtering side, DevHelm's notification policies and severity-based alerting can help reduce the noise before it reaches your on-call channel. But the structural fixes come first. No tool fixes a four-person rotation with no recovery time.
Originally published on DevHelm.
Top comments (0)