Beyond the four golden signals, what SRE metrics should a platform team track to know if their own on-call process is becoming unsustainable before people start quitting or burning out?

Most teams instrument their services obsessively — latency, error rate, saturation, traffic — but treat the health of the humans operating those services as something you just informally sense from morale or notice only after someone quits. That's like a factory meticulously monitoring every machine on the line while never checking whether the workers running those machines are being pushed past a sustainable pace — the machines can look perfectly healthy on every dashboard right up until the workers operating them start walking out, at which point it's far too late to have caught the problem early. On-call sustainability deserves the same instrumentation discipline as the services it protects, precisely because human burnout, like service degradation, has measurable leading indicators long before it becomes a visible, painful lagging one.

This reframing — treating the on-call process itself as a system with SLIs, not just a duty roster — exists because burnout is otherwise almost always caught too late. Exit interviews and engagement surveys are lagging indicators; by the time someone reports burnout in a survey or, worse, resigns, the underlying operational conditions that caused it have usually been present and worsening for months. A platform team that only reacts to those late signals is running on-call reactively in exactly the same way a service that only alerts on outright downtime, rather than leading indicators of degradation, is running reliability reactively.

Step by step, the metrics worth building dashboards around: toil percentage — the fraction of on-call hours spent on manual, repetitive interventions that could in principle be automated, tracked weekly per person and per team, with a rising trend flagged well before it crosses an unsustainable threshold (commonly cited around 50%). Pages per shift — both the raw count and its trend over time, since a rotation that used to average one page per shift creeping toward four or five over a few months is a measurable early warning even if no single week looks alarming in isolation. After-hours and overnight page rate specifically, separated from business-hours pages, because a page at 3 AM has a categorically different human cost than the same page at 2 PM, and blending them into one aggregate metric hides exactly the dimension that correlates most directly with burnout and sleep disruption. Mean time to acknowledge and its trend — a rotation where acknowledgment times are quietly creeping up over weeks is often an early, indirect signal that on-call engineers are increasingly reluctant to engage quickly, frequently because they've learned from experience that pages are usually low-value noise rather than genuine emergencies.

At organizational scale, the most mature teams review these on-call health metrics in the same recurring operational review cadence as service-level reliability metrics — not as a one-off survey exercise, but as a standing agenda item with an owner and a trend line, exactly like an SLO dashboard. This normalizes discussing on-call sustainability as an ongoing engineering concern with real data behind it, rather than an occasional, hard-to-quantify cultural conversation that only comes up after morale has already visibly deteriorated.

The gotcha: teams that track these metrics in aggregate across an entire large team can miss a severe, concentrated burnout risk sitting on just one or two individuals — if one person is disproportionately picking up extra shifts, covering for a teammate on leave, or handling most of the after-hours pages because they happen to respond fastest, a team-wide average of 'reasonable' pages per shift can look completely healthy while that one specific person is quietly approaching burnout, invisible until the aggregate view is broken down per individual rather than only viewed at the team level.