Incident metrics have a strong pull toward the ones that are easy to compute rather than the ones that are useful.
The standard set
MTTA, mean time to acknowledge, measures your alerting and rotation. MTTR, mean time to resolve, is the headline metric everywhere. MTBF, mean time between failures. These are fine; the problem is what they hide.
Why the mean is the wrong statistic
Incident durations are heavily skewed. Twenty incidents at four minutes and one at nine hours gives an MTTR of about twenty-nine minutes — a duration no incident actually had. Track the median and the p90 instead. If you report one number, report p90; it is the honest one.
Where the clock starts is a policy decision
MTTR is trivially gamed by changing when the timer starts. If it starts at human acknowledgement, a team with terrible detection can post an excellent MTTR. If you can measure the gap between "problem started" and "incident opened" separately, that gap is pure detection quality.
Four metrics worth adding
Percentage of incidents detected by monitoring rather than by a human — every incident that came in through support is a specific monitoring gap. Repeat rate — the metric most correlated with a team that feels like it is drowning. Pages outside working hours per person, looking at the maximum not the mean. Time from resolved to closed.
Auto-resolution distorts everything
If incidents auto-resolve when a check recovers, a large share will have near-zero MTTR without anyone doing anything. Split auto-resolved from human-resolved and report them separately.
What to do with the numbers
Use them as questions, not targets. p90 rose — which incidents drove that? Repeat rate is 40% — which cause is recurring? One person took nine night pages — is the rotation broken? Each leads somewhere concrete; "reduce MTTR by 20%" leads to arguing about definitions.