Most engineering teams track exactly one incident response metric, and it is usually MTTR. It appears on the quarterly slide, it goes up or down by a few minutes, someone says "we need to bring that down," and nothing about the next incident changes. The problem is not that teams measure the wrong thing out of laziness. The problem is that incident response metrics are genuinely hard to design, and a single average duration is the easiest number to produce from an incident tracker. It is also the number least likely to tell you what to fix.

This guide is about the metrics that actually change behaviour: how to decompose the incident timeline into stages that have owners, how to measure alert quality without turning it into a blame exercise, how to track on-call health before people burn out rather than after, and how to instrument all of it without standing up a six month data project. Everything here assumes a small to mid sized engineering organisation, not a company with a dedicated reliability analytics team.

Why MTTR is a weak headline metric

MTTR is not useless. It is a reasonable smoke detector: if it triples over two quarters, something real has changed. But as a target, it fails in three specific ways, and understanding those failures is what points you toward better metrics.

Incident duration is heavily skewed, so the mean is fragile

Incident durations do not follow a normal distribution. A typical quarter has a long tail of short incidents (a noisy alert, a self-healing pod, a five minute blip) and a small number of very long ones. When you average those together, one bad Saturday can swamp forty routine pages. The VOID, the open incident database assembled by Courtney Nash, has made this argument in detail across thousands of public incident reports: duration data is right-skewed enough that a mean carries wide error bars, and comparing means between quarters or between teams often measures nothing but which quarter happened to contain a bad tail event.

The practical fix is not complicated. Report the median and the 90th percentile alongside the mean, and treat them as different questions. The median tells you about your routine, everyday response. The p90 tells you about the incidents that hurt. They usually move for completely different reasons, and a change in one should not be read as a change in the other.

MTTR bundles stages with different owners

A single duration number collapses at least five distinct phases: the system broke, monitoring noticed, a human was paged, that human acknowledged, the right expert got involved, and the problem was mitigated. Each of those gaps has a different cause and a different fix. Detection gaps are a monitoring problem. Acknowledgement gaps are a paging and escalation problem. Time to the right responder is an ownership and routing problem. Time to mitigation is an architecture and runbook problem.

When you report only the total, you cannot tell whether your last quarter got worse because your alerts got slower or because your rollback procedure got more complicated. You end up with a number that everyone agrees should be lower and nobody knows how to lower.

MTTR improves for bad reasons

This is the failure mode that should worry you most. MTTR goes down when responders close incidents faster, and closing an incident faster is not the same as fixing it faster. Teams under pressure to improve the number will, entirely rationally, start declaring incidents resolved at mitigation rather than at resolution, downgrading ambiguous events so they never become incidents, or reclassifying a recurring problem as "known issue, not an incident."

None of that is dishonest in any individual case. In aggregate it hollows out the metric. Any metric that responders can improve by changing how they label things, rather than by changing how they respond, will eventually be improved that way. This is Goodhart's law applied to reliability, and it is the main reason to prefer a small basket of metrics over one headline figure.

Decompose the timeline into stages you can act on

The single highest leverage change most teams can make is to stop measuring one interval and start measuring four. You need four timestamps per incident, and if your on-call tooling is reasonable you already have three of them.

Time to detect

Measured from the first customer-visible symptom to the first alert firing. This is the hardest to capture because the start time is often reconstructed after the fact from graphs, but it is the most valuable. A team with a 40 minute detection gap and a 5 minute response cannot fix its numbers by paging faster.

The metric that pairs with this is detection source: what fraction of incidents were found by monitoring versus by a customer, a support ticket, or an engineer who happened to notice. If more than roughly a fifth of your significant incidents arrive through a human channel first, your alerting has a coverage problem, and no amount of escalation tuning will help. Google's SRE material on monitoring distributed systems makes the case for alerting on symptoms that users actually experience rather than on internal causes, and detection source is the metric that tells you whether you have managed it.

Time to acknowledge

From the page firing to a human confirming they have it. This is the cleanest metric in the whole set, because both timestamps are unambiguous and both are inside your tooling. It is also the one most directly under your control: it is a function of notification reliability, escalation timeout configuration, and whether the person on call actually received the page on a device that was awake.

Track it as a distribution, not an average, and watch the tail specifically. A p50 of 90 seconds with a p95 of 22 minutes tells you the system works most of the time and fails badly sometimes, which usually points at one broken notification path (a phone on silent, an escalation policy with a 15 minute first hop, a channel notification nobody has enabled) rather than at a team that is slow.

Time to the right responder

From acknowledgement to the moment someone with the relevant context and access is engaged. This is the interval nobody measures and everybody feels. The first responder on a generic rotation frequently cannot fix the thing that broke; their real job is triage and routing. If that routing consistently takes 20 minutes, the fix is ownership metadata and clear service to team mapping, not faster acknowledgement.

A cheap proxy: count the number of escalation hops per incident, and the number of distinct people pulled into the incident channel before the eventual fixer arrives. Both are easy to extract and both correlate well with how painful an incident felt.

Time to mitigate versus time to resolve

Keep these separate and define them explicitly:

Time to mitigate: customer impact has stopped. The rollback landed, traffic is shifted, the feature flag is off.
Time to resolve: the underlying defect is fixed and the temporary measure has been unwound.

Mitigation time is the number that reflects your operational readiness, and it is the one worth optimising. Resolution time reflects engineering priorities and often stretches across weeks, which makes it useless as an operational metric but quite useful as a signal about technical debt. Reporting them as one number, which is what most default incident tooling does, makes both meaningless. This distinction also lines up with how DORA frames failed deployment recovery time: what matters for delivery performance is how quickly service is restored, not how quickly the root cause is permanently eliminated.

Metrics for alert quality

Alert quality is where incident response metrics pay off fastest, because bad alerts impose a continuous cost on people who are not currently in an incident. These three metrics are cheap to compute and unusually hard to game.

Actionability rate

The percentage of pages where the responder did something other than acknowledge and close. This requires one piece of human input, so keep it to a single click: when an alert is resolved, ask whether it required action. A two option prompt in the incident channel gets high compliance; a form does not.

Healthy teams land somewhere north of 70 percent. Below 50 percent, the on-call engineer has learned that most pages are noise, and their acknowledgement latency on the pages that do matter will drift upward accordingly. That drift is the real damage from alert noise, and it is invisible if you only track average acknowledgement time across all alerts.

Noise concentration

Do not just count total alerts. Count how many distinct alert rules produced 80 percent of your pages last month. In almost every team that runs this query for the first time, the answer is a handful, often three to six rules that everyone already knows about and nobody owns fixing. Publishing that list monthly, with a named owner per rule and a required decision (tune the threshold, add a dependency suppression, convert it to a ticket, or delete it) converts a vague complaint about noise into four or five concrete pieces of work.

Off-hours page rate

The count of pages that fired outside working hours, tracked per person and per team. Split this from the total: an alert that fires 30 times during business hours is an annoyance, and the same alert firing three times at 3am is a retention problem. Any rule that has woken someone up twice in a quarter without requiring immediate action should have to justify its existence as a page rather than a ticket.

Metrics for on-call health

These are lagging indicators of the ones above, and they are the metrics most likely to be missing entirely. They are also the ones that predict attrition.

Interrupt load distribution

Total pages per rotation tells you very little. Pages per person, sorted, tells you a great deal. The common pathology is not that a team is overloaded on average but that one or two people absorb a wildly disproportionate share, either because they are the informal expert everyone escalates to or because their shifts happen to land on a recurring failure window.

Look at the ratio between the most paged and the median paged person on each rotation. Above about three to one, you have a concentration problem, and the fix is usually knowledge distribution (runbooks, shadowing, expanding the rotation) rather than schedule shuffling.

Sleep interruption count

Track nights where an individual was paged between roughly 11pm and 7am in their own timezone, per quarter. This is the single most predictive on-call health metric and almost nobody records it. Set an explicit budget, publish it, and treat exceeding it the way you would treat exceeding an error budget: as a trigger for work, not a topic for sympathy.

Handover completeness

Measured crudely as the percentage of shift handovers that included a written summary of open issues. It sounds bureaucratic and it is the cheapest reliability win available to most teams, because the incidents that go worst are frequently the ones where the previous shift knew something the current shift does not.

Metrics for learning rather than scoring

Action item completion and age

Postmortems generate action items. Most organisations never check whether those items ship. Two numbers fix this: the percentage of action items from incidents older than 30 days that are closed, and the age of the oldest open item. Both belong in the same review as your incident counts, because an incident process that produces work nobody does is a documentation exercise with extra steps. The Google SRE material on postmortem culture is emphatic on this point: the value of a blameless review is entirely in the follow-through.

Repeat incident rate

The percentage of incidents in a period that share a root cause with an incident from the previous two quarters. This requires tagging incidents by cause category, which is 15 minutes of taxonomy work and pays for itself immediately. A rising repeat rate with a falling MTTR is the clearest possible signal that a team has become excellent at handling a problem it should have eliminated.

Severity accuracy

Compare the severity assigned when the incident was declared against the severity it was assigned at review. Systematic under-declaring means responders are afraid of the process overhead of a high severity incident, and they will keep under-declaring until you make that process cheaper. Systematic over-declaring means your severity definitions are unclear. Either way the fix is in the process, not in the responders.

Instrumenting this without a data project

Nearly everything above can be derived from four timestamps and three tags per incident. You do not need a warehouse. A practical sequence:

Week one: agree written definitions for detected, acknowledged, mitigated and resolved. Put them somewhere the on-call engineer will actually see them, and accept that the definitions matter more than the precision.
Week two: make recording those timestamps a byproduct of responding rather than a separate task. If declaring an incident, acknowledging a page and marking mitigation all happen in the tool the team already lives in, the data collects itself. If it requires a second system, it will not get filled in during the incident, and reconstructed timestamps are worth very little.
Week three: add the three tags (cause category, detection source, actionable yes or no) as one click options at resolution time.
Week four onward: publish a short monthly review with distributions rather than averages, and pick exactly one metric to improve per quarter.

That last constraint matters more than it sounds. A dashboard with 14 reliability metrics gets glanced at; a review that says "this quarter we are reducing off-hours pages on the payments rotation, here is the number today" produces work.

This is also where the location of your tooling stops being a matter of taste. Timestamps captured in the flow of the response are accurate; timestamps entered afterward are fiction. When paging, acknowledgement, incident declaration and status updates all happen inside Slack, where the team is already coordinating, the data is a free side effect of the work. This is the main reason we built Pagerly as a Slack-native on-call and incident management tool rather than as another console to context switch into: the acknowledgement timestamp is real because acknowledging happened in the channel where the conversation was already occurring, and the resolution tag gets filled in because it is a button on a message someone is already reading.

Anti-patterns worth naming

Comparing MTTR across teams. A team owning a stateless API and a team owning a data pipeline have structurally different recovery profiles. Comparing them produces resentment and no insight.
Individual response time leaderboards. The fastest way to teach people to acknowledge pages without reading them.
Counting incidents as a quality metric. Incident count is mostly a measure of how willing people are to declare incidents. A team that declares more is usually healthier, not worse.
Targets without budgets. "Reduce MTTR by 20 percent" with no allocated engineering time is a request for creative labelling.
Measuring for a quarter and stopping. These metrics are only useful as trends. The first three months of data mainly teach you that your definitions were wrong.

What to take away

The point of incident response metrics is not to produce a score. It is to turn a vague sense that on-call is painful into a specific claim about which stage of the response is slow, which alerts are lying, and which people are absorbing more than their share. Those claims can be argued with, prioritised and fixed. An average duration cannot.

Replace one duration with four stage intervals: detect, acknowledge, route, mitigate.
Report medians and p90s. Averages of skewed data mislead in both directions.
Separate mitigation from resolution and optimise only the first operationally.
Track actionability rate and off-hours pages as first class metrics, not as complaints.
Watch interrupt load per person, not per team, and treat a three to one ratio as a defect.
Measure action item completion, or accept that your postmortems are theatre.
Pick one metric per quarter and fund the work to move it.

If you only adopt one thing from this list, make it the split between detection and response. Most teams discover, uncomfortably, that they are fast at the part they have been optimising and slow at the part they never measured. That discovery is worth more than another quarter of watching a single average drift.