On-call rotations exist to catch the 2am database failover that nobody’s watching, but badly designed ones just create a rotating cast of exhausted engineers who dread their week. A rotation that actually works balances response speed against sustainable workload, and that balance is measurable, not a matter of luck or team culture.
What a Healthy On-Call Rotation Actually Looks Like
A sustainable rotation has three properties: predictable scheduling, a realistic alert volume, and a clear escalation path when the primary responder can’t fix things alone. Most teams get the schedule right and ignore the other two, which is why engineers still burn out even with a fair calendar.
PagerDuty’s 2023 State of Digital Operations report found that 44% of on-call responders had experienced burnout tied specifically to alert volume, not shift length. That’s the detail teams miss — a rotation can be perfectly fair on paper and still wreck someone’s month if every shift means 30 pages.
Sizing the Rotation Correctly
A rotation of fewer than 5 people means everyone is on call roughly one week in five, which is workable short-term but grinding over a year. Below 4 people, plan on turnover — engineers start job-hunting once on-call becomes a monthly fixture rather than an occasional one.
For a team of 8-10 engineers, a 1-week primary / 1-week secondary rotation with a 6-8 week gap between primary shifts is the sweet spot most SRE teams converge on. Google’s SRE workbook recommends capping on-call load at 2 events per 12-hour shift as a target ceiling before a rotation needs redesigning, not just more people added to it.
Smaller teams — 3 or 4 engineers, common at seed-stage startups — can’t hit that ratio. In that case, the honest fix isn’t a better schedule, it’s cutting the number of things that can page someone at 3am. That usually means tightening monitor thresholds and consolidating alerts so a single root cause doesn’t fire five pages, something covered in more depth in how to reduce false positive alerts without missing real issues.
Fixing the Alert Signal Before Fixing the Schedule
how to choose between email, SMS, and webhook alerts for the tradeoffs.Common Mistakes Teams Make
Three patterns show up repeatedly in teams that burn out their on-call engineers:
Paging the same person for every incident type. When one senior engineer is the unofficial fallback for anything the primary can’t solve, they’re effectively on call 24/7 regardless of the published schedule. This is the single most common cause of quiet, unreported burnout.
No secondary escalation path. If the primary doesn’t acknowledge a page within 5 minutes and there’s no automatic escalation to a backup, the alert either goes unanswered or someone checks their phone obsessively out of anxiety, which is its own form of burnout even without actual pages.
Treating on-call compensation as optional. Teams that don’t pay for on-call time, in cash or in comp days, see resentment build even when the actual page volume is low. It’s not really about the money — it’s an acknowledgment that the week has a cost.
Busting the “More Redundancy Fixes Burnout” Myth
A common assumption is that adding more people to the rotation automatically fixes fatigue. It doesn’t, unless the underlying alert volume also drops. Ten engineers rotating through a schedule that generates 50 unnecessary pages a week just spreads bad signal-to-noise across more people — it doesn’t reduce the noise. Teams that scale headcount without first tightening alert quality often see burnout complaints persist at the same rate, just distributed differently.
The actual fix order is: reduce false positives first, tier severity second, then size the rotation to the remaining real page volume. Doing it in reverse order means guessing at headcount against a number that keeps changing.
Building the Escalation Path
A functioning escalation chain has at minimum three tiers: primary responder, secondary/backup, and an engineering lead who gets paged automatically if nothing is acknowledged within a set window — typically 5-10 minutes for customer-facing outages. Tools like PagerDuty, Opsgenie, and Splunk On-Call all support this natively, but the logic only works if someone actually tests it.
An experienced ops lead schedules a quarterly “fire drill” — a deliberate, announced test page sent outside business hours — to confirm the escalation chain actually reaches a human and that phone numbers and Slack integrations haven’t gone stale. Skipping this is how teams discover, during a real outage, that the secondary’s phone number was updated six months ago and nobody updated PagerDuty.
Once an incident does happen, closing the loop matters as much as catching it — a rotation that never runs post-incident reviews just repeats the same failures on the next shift. For that step, see how to run a post-mortem after a website outage.
Frequently Asked Questions
How many people should be in an on-call rotation?
A minimum of 4-5 engineers is the practical floor for sustainability, giving each person roughly one week on call every 4-8 weeks depending on team size and secondary coverage. Teams smaller than that should focus on reducing alert volume rather than trying to force a fair rotation out of too few people.
Should on-call engineers be paid extra?
Most mature engineering organizations compensate on-call time separately from base salary, either as a flat weekly stipend ($100-300/week is common in the US) or as comp time. Teams that skip this tend to see on-call resentment rise even when the actual workload is light, because the lack of acknowledgment feels dismissive of the disruption to personal time.
What’s a reasonable number of pages per on-call shift?
Google’s SRE guidance targets no more than 2 actionable events per 12-hour shift before a team should treat it as a signal to fix underlying alert quality. If a rotation regularly sees 5+ pages per shift, the problem is almost always alert calibration, not staffing.
A rotation that respects both the schedule and the signal quality behind it doesn’t need heroics to stay sustainable — it needs a quarterly look at page volume, honest severity tiering, and an escalation chain that’s actually been tested. Skip any one of those three and burnout comes back regardless of how fair the calendar looks on paper.