How do I measure pager fatigue in a way that actually convinces leadership?

You're spot on about opportunity cost. That marketing campaign delay example is perfect because it's concrete. I've seen teams miss deadlines for security audits or compliance checks after a bad on-call week, which can have real contract implications.

The "hire more engineers" question is such a classic trap. That's exactly where the false-positive data wins. You can show that even with more people, the bad alerts just burn more capacity. Fixing the alerts is the multiplier.

Your three starting metrics are fine, but they're still too internal. Finance doesn't care about "false positive rate," they care about "wasted investment."

The dashboard that worked was just a two-line chart. Top line: total hours of alert handling per engineer (pulled from ticket logs, not self-report). that same engineer's story point completion rate from Jira, lagged by 48 hours.

When you show a high-alert week followed by a 35% drop in delivered points the next week, you're not talking about fatigue. You're talking about a quantifiable 35% drop in ROI on that engineer's salary for that period. That gets their attention. Map the "alerts outside working hours" directly to a line item of "overtime cost or lost productivity recovery cost" on the P&L. Stop showing them ops data. Show them a broken business process.

Completely agree on mapping to "wasted investment." That's the only language finance respects.

The problem I've run into with the two-line chart is engineering pushback on story points as a productivity proxy. They'll argue that post-pager work often involves critical, unplanned tasks like fixing root causes or updating runbooks, which don't translate to story points. Leadership might then see the drop and say "the capacity was still used, just not on features."

A successful addition to your dashboard is a third line: hours logged against 'unplanned work' tickets in the same system. It shows the post-pager drop in planned output, but also captures where that capacity actually went. It proves the investment was wasted on firefighting, not lost.

You're absolutely on the right track with those three metrics, and I've seen them work. The key, as others have hinted, is the framing. Finance thinks in allocations and returns.

Take "alerts outside working hours that didn't meet severity threshold." Don't present it as a count. Present it as a calculation: "This consumed X hours of our planned sprint capacity for Q3, which directly delayed Project Y's launch by one week." That's a business outcome they already track.

The dashboard that works isn't fancy. It's a simple correlation chart with two data series: alert volume (weighted by handling time) from your on-call tool, and committed story points delivered from your project tracker, with a one-sprint lag. The visual dip after a bad on-call week is often all you need. It turns "fatigue" into "planned work not delivered."

Absolutely. That visual dip you describe is the only thing that worked for us. It cuts through the "but were they still working?" argument instantly.

We found one more layer that helped: tagging which projects got delayed. When you can say "The high-alert week of March 10th directly pushed the checkout refactor from Q2 into Q3," it goes from a chart to a tangible impact on the roadmap.

I love the "planned work not delivered" framing. It's a powerful shift.

Your metrics are backwards. You're trying to measure burnout by measuring alert behavior. That's noise. Burnout isn't about false positives, it's about total cognitive load per engineer per week.

You need the absolute simplest metric: hours spent on call tasks, logged in the ticket. Not just acknowledgment, total time interrupted. Then plot that against story points, commits, whatever output metric your leadership already believes in, lagged by a week.

If an engineer logs 12 hours of pager work, their output next week drops by at least 12 hours. That's not fatigue, that's a straight line item on the P&L. The financial loss is the salary cost of that lost productive time.

All your other metrics just argue about why the house is burning down. Show them the fuel consumption.

Self-reporting is a trap. It's just an extra, annoying step that gets skipped at 2 AM.

The trick is to bake the time logging into the alert resolution workflow. When you click "resolve" in PagerDuty or Opsgenie, it should auto-open a linked Jira ticket with a timer already populated from the alert's start time. Engineer just adjusts it if they worked past resolution, adds a note, and hits close.

If your tooling can't do that, then it's part of the problem. You're measuring fatigue with a process that causes more of it.

Great starting metrics, but you're right - leadership needs the translation. Those three become undeniable when you frame them as "wasted investment."

For example, **alerts outside working hours** isn't just a count. It's "X hours of unplanned overtime that directly pulled from Project Y's budget, delaying launch by two weeks."

The dashboard that clicked for us was super simple: a line chart of total on-call hours (logged in tickets) next to a line of story points delivered, with a one-week lag. When a bad on-call week is followed by a 40% drop in delivery, you're not showing fatigue, you're showing a 40% drop in ROI on that engineer's salary. Finance gets that language instantly.

You're 100% right about that pushback on story points, and that third line is the key. We learned the hard way that without capturing the unplanned work, leadership just sees a shift in priorities, not waste.

We actually added a *fourth* dimension that sealed it: tagging the unplanned work tickets by a simple 'recurrence' flag. If the hours went to fixing a brand new issue, that's one thing. But if the hours went to the same alert that fired three times last month? That's pure waste, and it shows the cost of *not* fixing the alerting system itself.

Your point about proving the investment was wasted on firefighting is exactly it. Once you can show that 60% of post-pager work is recurring noise, you've moved the conversation from "are they working?" to "why are we paying for the same fix over and over?"

That recurrence flag is a brilliant addition. We've found quantifying *repetitive* waste is what finally unlocks budget for alerting system improvements. It turns "engineer fatigue" into a clear reliability debt with a quantifiable interest rate.

One caveat we learned: you need a consistent taxonomy for "same alert." We started with simple title matching, but that broke with dynamic alert messages. We now use a combination of the underlying alerting rule ID and a service/error code, logged automatically by our pipeline to the ticket. Without that, your recurrence metric becomes a manual tagging burden and loses credibility.

It also creates a direct line from the pager metric to a business case: "30% of our unplanned work hours are recurring issues. A one-time investment of X engineering quarters to refactor these alerting rules would pay for itself in Y months by reclaiming that lost capacity." That's a FinOps argument they understand.