When an on-call rotation starts burning out the team, the first instinct is to look at the page count. It is almost never the right metric. The teams we have helped through this consistently find that the volume of pages is a symptom, not the cause. The cause is in the operating model around the pages.
The five questions to ask
Are the pages actionable? A page that wakes someone up at 3am to acknowledge a non-actionable alert is worse than no page at all. Every alert in the rotation should have a clear runbook and a clear "yes, act now" or "no, this can wait".
Is the on-call engineer protected from their day job? The single biggest predictor of on-call burnout is being expected to ship features at the same pace during an on-call week. Reduce the planning commitment for the on-call engineer by 50% and the burnout drops dramatically.
Is the rotation big enough? Below five engineers, a rotation burns people out regardless of page volume because everyone is on call too often. Above ten, the rotation tends to lose context. Five to eight is the sweet spot.
Do incidents produce learning? A team that pages, fixes, and moves on produces incidents indefinitely. A team that pages, fixes, runs a blameless review, and ships the prevention work produces fewer incidents over time. The engineering hours spent on prevention pay back the rotation in months.
Is the on-call work visible? On-call is one of the most demanding parts of an engineer's job. If it is not visible in performance reviews, in compensation, and in promotion criteria, it is being subsidised by the goodwill of your most senior engineers — and that subsidy runs out.
What healthy on-call looks like
The teams whose on-call works well share a few properties. The volume of actionable pages is below five per week per engineer. The on-call engineer's calendar is mostly clear of meetings. There is a follow-up project list from incidents, and it is actively worked. New joiners shadow before they are primary, and the runbooks are written well enough that an off-hours fix does not require waking a senior engineer.
Burnout is a systems problem, not a people problem. Fix the system.