A team of three engineers can finish a week with fewer pages than usual and still arrive at Monday exhausted, because page count records interruptions, not the work and uncertainty surrounding them.
That distinction matters. Page count is easy to put on a dashboard, easy to compare across rotations, and easy to explain to leadership. It is also a lagging indicator of on-call health. By the time page volume rises enough to look alarming, the rotation may already be carrying pager debt, slower recovery, and a growing reluctance to take ownership of the next shift.
I have spent enough time on platform teams to distrust any on-call review that starts and ends with "How many pages did we get?" The better question is what those pages did to the shift. How long did they take to understand? How many required follow-up after the immediate symptom disappeared? How often did an engineer decide that a page was not worth escalating because the escalation path was unclear?
Page count measures interruption, not load
A page is an event. On-call load is the total cognitive and operational cost of handling that event.
One page can be a five-minute acknowledgment followed by an automated rollback. Another can arrive at 2:00 a.m., point to a generic latency alert, require log correlation across four services, and end with an engineer watching graphs for an hour because nobody knows whether the underlying failure has stopped. Both count as one page. They do not consume the same shift.
Page count also hides clustering. Four pages spread across a twelve-hour shift may be manageable. Four pages in forty minutes can destroy the same shift, particularly when the engineer is still holding context from the first incident. The work between pages matters too. A page may trigger a mitigation, a customer-impact review, a ticket for permanent repair, and a handoff note. None of that appears in the page total.
There is a second problem: page count encourages teams to optimize the number instead of the system. A noisy alert gets tuned out, its threshold is raised, or its severity is lowered. The dashboard improves while detection gets worse. Fewer pages can mean fewer incidents, or it can mean that the team has stopped trusting the pager.
That is why I treat page count as a useful descriptive metric, not a health score. It tells us how often the paging system interrupted someone. It does not tell us whether the rotation is sustainable.
The signals that show load earlier
A more useful view combines interruption, response, and recovery signals. No single metric captures the experience of a shift, but a small set can expose strain before a rotation breaks down.
- Interruptions per shift: Count pages, but also record the number of distinct interruption windows. Six pages in one burst is operationally different from six isolated pages.
- Time to detect and time to acknowledge: TTD and MTTA show whether alerts are being noticed and accepted promptly. A rising MTTA can indicate fatigue, alert distrust, or an overloaded engineer even when page volume is flat.
- Time to actionable diagnosis: Measure how long it takes to identify a likely failure mode and a safe next step. This is often more informative than time to acknowledge, especially for alerts that technically reach the right person.
- Time to recovery: MTTR remains useful, but it should be paired with a note about whether recovery came from a known runbook, a repeatable automation, or improvised debugging.
- Escalation rate: Track how often the primary on-call needs a secondary, a service owner, or a manager. Escalation is not failure. A sudden increase can reveal unclear ownership, missing permissions, or incidents that exceed the rotation's intended scope.
- After-hours follow-up: Count the incidents that produce work after the shift, including investigation, cleanup, post-incident review, or a fix that the on-call engineer carries into the next day.
- Repeat incidents: A recurring alert that receives the same manual treatment is a form of pager debt. Track the recurrence and the time spent, not only the initial page.
These signals work best when viewed together. A week with stable page count, rising MTTA, and more secondary escalations deserves attention. So does a week with low page volume but a high share of incidents requiring prolonged diagnosis.
A quiet week by count can still be brutal
Consider a synthetic example: a platform team of eight engineers rotating a seven-day primary on-call shift. During one week, the primary receives 14 pages, down from 22 the week before. The weekly review initially calls this an improvement.
The distribution tells a different story. Ten of the 14 pages arrived during two overnight bursts. Three were symptoms of the same database connection problem, but the alerts came from different services and sent the engineer down separate investigative paths. The remaining pages were low urgency but ambiguous. None had a clear owner, so the primary spent time checking dashboards and asking in team chat before deciding whether to escalate.
The rotation's numbers look deceptively healthy:
- Pages per shift fell from 22 to 14.
- MTTA stayed near five minutes.
- There were no missed pages.
But the leading indicators were deteriorating:
- The primary spent nearly three hours in active overnight investigation.
- Two incidents required secondary escalation.
- Average time to actionable diagnosis increased from 18 minutes to 47 minutes.
- Four hours of follow-up work moved into the next business day.
The engineer did not experience a quiet week. They experienced a concentrated week with uncertain diagnosis and unfinished work. If the team had reviewed only page count, it would have rewarded the wrong conclusion and left the underlying failure modes in place.
Measure cognitive load without pretending it is perfectly precise
Cognitive load is harder to measure than pages because it includes context switching, uncertainty, and the effort of deciding what to do next. That does not make it too subjective to track. It means the measurement needs a practical proxy.
For each incident, capture a few structured fields in the incident timeline:
- Minutes from page to first plausible diagnosis.
- Number of services or dashboards inspected before a decision.
- Whether the mitigation was documented and repeatable.
- Number of handoffs or escalations.
- Whether follow-up work remained at shift end.
- A simple post-shift rating, such as low, moderate, or high effort.
The rating is not a replacement for operational data. It is a way to catch what telemetry misses. If an engineer marks a familiar rollback as low effort, but marks a single ambiguous alert as high effort, that distinction should influence alert design and runbook work.
It is also useful to calculate a rough interrupt load per shift. One team might define it as the number of interruption windows multiplied by the average minutes spent in active handling. Another might weight overnight incidents more heavily because they impose a different recovery cost. The exact formula matters less than using the same definition consistently and inspecting the incidents behind the score.
Do not turn this into a ranking of individual engineers. Load metrics are for improving the rotation and the systems it supports. Comparing engineers by MTTA or escalation rate without context creates incentives to acknowledge pages quickly, avoid escalation, or close incidents before the risk is understood.
What good measurement changes
Once a team sees more than page totals, its remediation choices usually become more specific.
High interruption density points toward deduplication, grouping, maintenance windows, or alert inhibition. Long time to actionable diagnosis points toward better context in the alert, clearer service ownership, and runbooks that begin with likely failure modes instead of generic links. High escalation rates may indicate a permissions problem or an ownership boundary that exists only on an architecture diagram. Repeated after-hours follow-up is a signal that the team is paying for temporary mitigation with daytime capacity.
Automation can help with some of this work. A production system that detects an incident, gathers relevant context, and proposes or applies a safe repair can reduce the amount of investigation that reaches the on-call engineer. At Cordant, this is the problem we think about: waking an engineer only when a human decision is genuinely required. That is a product perspective, not a claim that automation removes the need for measurement. Teams still need to verify that incidents are being detected, diagnosed, and resolved safely.
There is a boundary here: no metric can determine whether an on-call rotation is healthy without operational context. A low MTTA may reflect good alerting, or it may reflect an engineer sleeping beside the phone. A low escalation rate may reflect strong ownership, or it may reflect a team that has normalized handling everything alone. Metrics should prompt investigation, not replace it.
The page count still belongs on the dashboard
The answer is not to discard page count. It remains useful for spotting changes in alert volume, comparing similar services, and finding obvious noise. It becomes misleading only when the team treats it as the complete definition of on-call burden.
For a weekly review, I would put page count beside interruption windows, MTTA, time to actionable diagnosis, recovery time, escalation rate, and follow-up hours. Then I would select one or two incidents and read the timeline. The timeline is where the number acquires meaning: whether the alert had enough context, whether the responder knew who owned the service, whether the mitigation was safe, and whether the same work will happen again next week.
The practical test is simple. Can an engineer looking at the dashboard explain what made the shift difficult, and can the team identify a change that will make the next shift easier? If the only answer is "we had 14 pages," the measurement is not finished. The page count may be accurate, but it is still missing the operational cost that the rotation is actually paying.