MTTD (Mean Time to Detect)
MTTD is the average time from when an incident actually begins until your team recognizes it — measuring how quickly monitoring, alerts, and on-call practices surface real production problems.
On this page
MTTD — mean time to detect — is the average time between when an incident actually starts (impact or credible risk begins) and when your team knows about it and begins a coordinated response.
Detection is the first domino. If you find out late, every downstream metric — including MTTR — starts from a worse position. Strong structured incident management assumes you can trust your signals and route them to someone who will act.
Why it matters
Customers often experience problems long before an engineer opens a laptop. Every minute of undetected impact is silent damage: failed checkouts, stale data, broken integrations. MTTD makes that gap visible and pushes teams to invest in observability, alert quality, and on-call coverage — not just faster fixes after the page fires.
Example
A database replication lag starts at 09:12 but only triggers an alert at 09:38 when read latency crosses a threshold. MTTD for that incident is 26 minutes. If customers reported the issue at 09:20 via support, your effective detection was eight minutes via humans — worth comparing to automated detection when you review the timeline.
Common mistakes
- Equating “alert fired” with “detected” when the alert threshold is too loose or monitors the wrong signal.
- Ignoring customer-reported incidents in MTTD calculations — they reveal blind spots in monitoring.
- Flooding on-call with noise — high alert volume slows real detection; see alert fatigue.
- Tracking MTTD without SLIs — if you do not define what “good” looks like, you cannot define when “bad” started.
Improve MTTD by aligning monitors to user-visible SLIs, tuning thresholds, and ensuring pages reach the current on-call through a clear escalation policy. Detection and recovery are different skills; measure both.