At some point in the last year, someone on your team said "on-call is getting rough." You nodded, maybe added a person to the rotation, maybe promised to look at the alert volume. The problem didn't go away. It rarely does, because the decision about how to structure on-call coverage almost never gets treated as a decision — it gets treated as a scheduling task.
Here's the actual problem: coverage and burnout aren't opposing values you balance through goodwill and rotation fairness. They're outputs of a system you either design or inherit by default. And most teams inherit it.
The Math You're Not Doing
Before you restructure anything, you need three numbers. The on-call schedule math is straightforward: take your total pages last quarter, divide by 13 weeks, divide by the number of engineers in the rotation. If that number exceeds three pages per engineer per week, you have a burnout problem in progress — not a risk, a reality. The second number is your off-hours fraction. If more than 30% of pages are hitting outside business hours, you've quietly converted on-call into a second job. The third is trajectory: is page volume growing quarter over quarter? If yes, the rotation math gets worse every cycle even if you don't change anything.
Most teams skip this entirely. The rotation gets designed in a Slack thread by whoever has scheduling access, and then the team lives with it for years. The math is almost never done, and the result is predictable: a few engineers burn out and quit, and management is surprised.
The broader burnout data makes the stakes concrete. According to the Haystack State of Burnout in Tech report (via DevX), more than 80% of developers report feeling burned out, and nearly half have considered leaving the industry. On-call isn't the only driver, but flat teams shouldering operational and on-call duties without backup are a specific pattern the data keeps surfacing.
The Coverage Decision Has Two Levers, Not One
When coverage feels thin, the instinct is to add people to the rotation. Sometimes that's right. But there are two distinct levers here, and most teams only pull one.
Lever one: rotation size. Fewer than four or five people in a rotation and everyone is on-call too often to recover. Below that threshold, the fix is hiring or merging rotations — not asking people to push harder. Weekly rotations are the right default: long enough to amortize handoff overhead, short enough that a bad week ends. Month-long primary shifts are corrosive.
Lever two: page volume. This is the one teams underinvest in. A two-tier primary-plus-escalation structure can help distribute cognitive load — the primary handles the documented 80% of incidents, the escalation tier absorbs the deep-knowledge residual — but its value depends entirely on runbook coverage. If your escalation rate is above 30%, you don't have a rotation structure problem. You have a runbook problem. The senior engineers are absorbing routine pages because the documentation doesn't exist or is out of date. Restructuring the rotation before fixing that just redistributes the pain.
The highest-leverage move in most rotations is alert auditing. Most pages don't deserve to be pages. Ruthless alert triage — cutting noise, fixing false positives, converting informational alerts to dashboards — is unglamorous and almost always the single highest-return investment you can make for on-call health. It's also the work that never gets prioritized because it doesn't ship features.
What Fair Actually Requires
Resentment kills rotations faster than pages do. Two things keep it from building.
First, compensate or comp the time. Whether it's pay, time off, or reduced project load during the on-call week, on-call is work and should be acknowledged as work. Pretending it's free is how you lose your best people — quietly, over months, as they stop volunteering for anything extra and start updating their LinkedIn.
Second, make the load visible. Publish the page counts. When engineers can see that burden is shared evenly — and that a brutal week earns recovery time — they tolerate the hard weeks. Hidden, uneven load breeds the kind of quiet resentment that shows up in your next engagement survey as "work-life balance concerns" with no actionable signal attached.
One structural trap worth naming: the named-escalation model, where a single senior engineer is always the escalation contact rather than rotating that role. This is structurally fragile and should be treated as an interim arrangement. It looks like coverage. It's actually a single point of failure with a face.
The Signal That Tells You It's Working
You're not looking for zero pages or perfect fairness. You're looking for a rotation that people can sustain for years without it becoming the reason they leave. The signal is simple: are your page-per-engineer numbers stable or declining quarter over quarter? Is the off-hours fraction manageable? When someone has a brutal week, does the system acknowledge it?
If you don't have those numbers, get them before you change anything. Most "we need more people on-call" problems are actually "we need fewer false pages" problems. The math will tell you which one you're actually solving.
