Module incident_metrics 

Incident Metrics

Incident response time decomposes into distinct phases: mean time to detect (MTTD), how long before the organization notices something is wrong; mean time to acknowledge (MTTA), how long before someone takes ownership of responding; and mean time to resolve or recover (MTTR), how long from ownership to genuine recovery. Reporting these separately, rather than only a single blended total, matters because each phase points to a different fix: slow detection points to a monitoring gap, slow acknowledgement points to an on-call process gap, and slow resolution points to a tooling or runbook gap.

Formula

MTTD          = mean(detection durations)
MTTA          = mean(acknowledgement durations)
MTTR          = mean(resolution durations)
Mean duration = mean(total incident durations)

Why it matters

Track incident frequency and MTTR together, never in isolation, mirroring DORA’s speed-and-stability pairing discipline: an improving MTTR alongside a rising incident frequency might indicate a team getting better at firefighting while underlying reliability actually degrades, and a falling frequency alongside a worsening MTTR might indicate rarer but more severe, harder-to-diagnose failures replacing frequent minor ones. Reviewing both together, rather than either alone, is what gives an honest combined picture.

Example

use software_engineering::incident_metrics::{
    mean_time_to_detect_minutes, mean_time_to_acknowledge_minutes,
    mean_time_to_resolve_minutes, mean_incident_duration_minutes,
};

let detection = [5.0, 15.0];
let acknowledgement = [2.0, 4.0];
let resolution = [30.0, 90.0];
let total = [37.0, 109.0];

assert_eq!(mean_time_to_detect_minutes(&detection), Some(10.0));
assert_eq!(mean_time_to_acknowledge_minutes(&acknowledgement), Some(3.0));
assert_eq!(mean_time_to_resolve_minutes(&resolution), Some(60.0));
assert_eq!(mean_incident_duration_minutes(&total), Some(73.0));

Pitfalls

• Reporting only a single blended total instead of the three decomposed phases — hides which specific gap (monitoring, on-call process, or tooling) is driving a slow response.
• Reviewing incident frequency and MTTR in isolation — misses the pattern where one metric’s improvement masks the other’s decline.
• Inconsistent severity classification across teams — makes organization-wide incident data as unreliable for comparison as inconsistently classified defect data.
• Extracting no systemic action items from postmortems — produces insight with no follow-through, wasting the organizational learning the process is meant to capture.

Sources

• Chapter 6.2, Incident metrics.

Topic doc: software-engineering-metrics/locales/en-001/chapters/06-02-incident-metrics.md

Functions

mean_incident_duration_minutes

Mean total incident duration, from detection start to full resolution — the blended total to report alongside, never instead of, the three decomposed phases above.

mean_time_to_acknowledge_minutes

Mean time to acknowledge (MTTA): the mean, across incidents, of the duration from notification to someone taking ownership of the response.

mean_time_to_detect_minutes

Mean time to detect (MTTD): the mean, across incidents, of the duration from a failure’s actual onset to someone noticing it.

mean_time_to_resolve_minutes

Mean time to resolve or recover (MTTR): the mean, across incidents, of the duration from ownership to genuine recovery.