Everyone loves to talk about "on-call wellness" until you ask for the numbers. Then you get hand-wavy nonsense about "team sentiment" or, worse, a dashboard showing nothing but alert volume and MTTR. As if a low number of pages automatically means a happy team.
If you're serious about proving your rotation isn't a burnout factory, you need to measure the *quality* of the interruption, not just the quantity. Alert volume is a vanity metric if every page is a hair-on-fire, context-less mystery.
Here's what I actually look at when evaluating a team's on-call load, usually buried in contract negotiations with monitoring vendors or during internal ROI reviews:
First, the **toil index**. How many alerts are just noise or require manual, repetitive action with no path to automation? Track the percentage of alerts that are auto-resolved, require no human action, or trigger a runbook. If this isn't trending up over time, you're just farming stress.
Second, **context-switch tax**. Measure the "time to context" – how long from the page until the engineer has the necessary logs, graphs, and runbooks loaded and understood. Long gaps mean your tooling is failing and the cognitive load is high. Also, track pages that occur outside of "response hours" but *within* a single on-call shift. A 2 AM page followed by a 6 AM page is far more destructive than two pages at 2 PM.
Finally, the **post-incident drag**. How much unpaid overtime is generated after a major incident? I look at the delta between the incident resolution time and the total calendar time until the post-mortem is finalized and action items are closed. A long tail of documentation and cleanup after a stressful event is where the real resentment builds.
If your leadership only cares about uptime percentages, they're incentivizing hiding pain. You need these operational metrics to argue for better tooling budgets, headcount, or contract terms with your alerting vendors. Anything less is just hoping people don't quit.
/charlie
Show me the TCO.
Agree on the quality over quantity point, but you're missing the biggest data point: follow-up work. If an alert is resolved but generates a post-incident todo (ticket, fix, doc update), that's a multiplier on the burnout factor.
You mentioned "time to context." I'd push further and measure "time to *correct* context." How often does the initial diagnostic data from the alerting system send someone down the wrong rabbit hole? That's where the real frustration builds.
And vendor contracts? Good luck. They'll always sell you on reducing alert volume, never on reducing the cognitive load of the alerts that remain. That's why you have to track your own "false start" metric internally.
-- bb
Spot on about the follow-up work. We actually started tagging post-incident action items in our ticketing system, and it was eye-opening. A "quick fix" alert that spawns three documentation tickets and a refactor discussion is a huge hidden tax.
Your "false start" metric hits home, too. We found that poor alert context didn't just waste time, it made people dread checking their phone. The stress of a potential wild goose chase at 2am is sometimes worse than a known, serious issue. That's a cognitive load metric I'd love to figure out how to track more formally.
Vendors absolutely avoid that conversation. They're selling peace of mind, not the gritty reality of mental overhead.
Tagging follow-up work is a good start, but you're just measuring the symptoms. The disease is letting that work exist in the first place.
> A "quick fix" alert that spawns three documentation tickets and a refactor discussion
This isn't a hidden tax. It's a choice. The team chose (implicitly or not) to treat the symptom over curing the disease. Every one of those spawned tickets is a process failure that should have been automated or eliminated, not tracked.
As for vendors selling "peace of mind," that's the real joke. Their peace of mind ends when the alert fires. The mental overhead you're describing is your problem, not in their SLA. They have zero incentive to reduce cognitive load because they can't charge for it.
trust but verify