We've onboarded to the same situation too many times: a startup with 15–30 engineers, a single DevOps hire who is the only person who understands the production infrastructure, and a PagerDuty rotation with one name in it. The engineer is good — sharp, experienced, committed. They've been paged 47 times in the last 30 days. When we ask about their on-call load, they say "it's fine." Their manager says the same thing. Six months later, we get a call: "Our DevOps engineer is leaving."
This is not bad luck. It is the predictable outcome of a structural design problem, and it happens regardless of how good the engineer is or how well they're paid. Understanding why — and how to fix it — matters whether you're about to make your first infrastructure hire or you're already watching the clock.
What on-call actually costs
The obvious cost is the salary. A senior DevOps engineer carrying 24/7 on-call responsibility as a solo act costs $180K–$220K fully loaded in most markets. But that's the cost on the invoice. The real cost is what doesn't show up on a spreadsheet:
- Cognitive load. Being on-call changes how you spend your non-on-call hours. Engineers describe it as "always half-awake." The phone could ring at 2am on Tuesday. It's Wednesday morning and you're in a design review, but part of your attention is somewhere else. Studies on interrupt-driven work consistently show that even when there's no active incident, on-call reduces cognitive availability by 20–40%.
- Sleep disruption compounding. A 3am page doesn't cost you 30 minutes — it costs you the rest of the night's sleep quality and the following day's performance. Three of those in a week is a different person by Friday. Sustained over months, it accumulates.
- The "vacation doesn't reset this" problem. A week off doesn't undo six months of disrupted sleep and hypervigilance. Engineers who've been doing solo on-call for 12+ months often report that they can't fully relax even when they're not on call — the reflex is trained in.
The 18-month figure isn't a rule, but it's close to the empirical average for how long engineers tolerate solo 24/7 on-call before they either burn out, leave for a role without it, or give notice after a particularly bad week. By that point, you've lost someone who took 3–6 months to become fully productive, and you're starting that clock again.
The alert volume problem
Most on-call burnout isn't caused by genuine outages. It's caused by noisy alerts — thresholds set too low, conditions that aren't actionable at 3am, and monitoring that was configured once and never maintained. We audit the alert history on almost every engagement. The pattern is always the same:
- 30–50% of pages are for conditions that resolved themselves before the engineer could investigate
- 15–20% are for known non-issues that nobody got around to filtering out
- 10–15% are for conditions that require action but not at 3am (a dashboard that looks concerning but isn't degrading service)
- 15–20% are genuine alerts that required intervention
An engineer who gets paged 40 times a month and only 8 of those pages required meaningful action is experiencing 32 false alarms — 32 interruptions to sleep and focus for no outcome. The solution isn't fewer alerts in aggregate; it's tiered alerting with a brutally maintained signal-to-noise ratio.
The framework we apply: every alert should have a documented runbook action. If there's no runbook action, it shouldn't be a PagerDuty alert — it should be a Slack notification or a dashboard metric. If the runbook action is "log in and check, then probably do nothing," that alert needs to be converted to a business-hours notification. Production outages page people. Everything else waits until morning or gets automated.
How to structure on-call that doesn't burn people out
Two people, always
A solo on-call rotation is a structural problem — it cannot be fixed by working harder or communicating better. The minimum sustainable rotation is two people with clearly defined escalation. Primary gets the page. If no acknowledgment in 10 minutes, secondary gets paged. If production is down for more than 15 minutes, CTO/VP Eng gets paged.
With two people, each engineer is on primary for one week at a time. Two weeks on-call per month means two weeks off. With three people, it's one week on per three-week cycle. That's the minimum — and even that's only sustainable if the alert volume is low (under 5 actionable pages per week).
Follow-the-sun for distributed teams
If your engineering team spans time zones, you have an asset you're probably not using. A US engineer and a EMEA engineer can split the 24-hour window so that neither is covering deep-sleep hours. The US engineer covers 8am–midnight their time; the EMEA engineer covers 8am–midnight their time. The overlap is a few hours; the coverage is clean.
This requires deliberate handoff documentation — a 5-minute async "here's what I saw today, here's what's active" at the timezone boundary — but it eliminates the 3am call for everyone. Most companies with distributed teams don't do this, not because it's hard, but because no one designed the process.
Compensate on-call separately
On-call is a distinct job function, not a line item buried in a salary negotiation. Engineers who carry production responsibility should have that acknowledged explicitly — either through on-call pay, additional time off, or reduced project workload during on-call weeks. The specific mechanism matters less than the acknowledgment.
Companies that treat on-call as an implicit part of a DevOps salary and then wonder why the DevOps engineer is always looking at LinkedIn are experiencing a compensation design problem, not an attitude problem.
When fractional teams change the math
For companies with 5–30 engineers who have a fractional DevOps team, the on-call structure looks different. We monitor client infrastructure 24/7 as part of every engagement. Our on-call rotation is staffed across multiple people and time zones. Incidents that come in at 3am are handled by someone who is awake, not by someone who was woken up.
The difference isn't just the coverage — it's the institutional knowledge. When an alert fires, the person responding has context on the system: they know it was deployed last Tuesday, they know the API has a known memory leak under high concurrency, they know that the certificate renewal is on a known issue. That context is what turns a 45-minute incident into a 10-minute incident.
We're not the right answer for every company. At a certain scale — 50+ engineers, complex infrastructure that requires deep institutional knowledge — you need an in-house SRE team. But for companies below that threshold, having your single DevOps engineer on-call every night is neither safe nor sustainable. It's a design choice with known consequences.
The incident postmortem you're not running
The most predictable pattern we see: an engineer leaves after a bad on-call stretch, a postmortem is never written, and the underlying alert volume and rotation design remain unchanged when the next engineer is hired. That engineer lasts 18 months and leaves. Repeat.
A blameless postmortem after every significant incident — not just the major outages, but the weeks where the alert volume spiked — is the process that generates the data to fix the underlying problem. Without it, on-call burnout isn't a people problem you'll hire your way out of. It's an infrastructure problem that quietly consumes engineers.
"We thought our DevOps engineer was just having a hard quarter. Then they gave notice. The next hire lasted 14 months. We finally fixed the rotation structure. The third person has been with us 3 years."