Most teams obsess over how fast they fix incidents, but the biggest hidden delay usually happens before anyone even knows something is wrong. MTTD (mean time to detect) is the average time between the moment a failure actually begins and the moment your team discovers it. It is the first clock in the incident lifecycle, and every minute it runs is added, untouched, to your total resolution time. You cannot acknowledge, diagnose, or fix what you have not detected.
This guide covers the MTTD formula with a worked example, how MTTD relates to MTTA, MTTR, and MTBF, what “good” looks like, and the practical levers that actually shorten detection time.
What Is MTTD (Mean Time to Detect)?
Mean time to detect (sometimes called mean time to discover or mean time to identify, MTTI) measures how long failures stay invisible. The clock starts when the fault condition actually begins, not when the first alert fires, and stops when a human or automated system recognizes that an incident is underway.
That distinction matters because detection can lag failure by a long way. A slow memory leak may degrade performance for hours before crossing an alert threshold. A silent data corruption bug may run for days until a customer complains. In each case, the service was failing the whole time; your monitoring just did not know yet.
MTTD applies in two related worlds:
- Operations and SRE: how quickly infrastructure and application failures are noticed, the sense used throughout this guide.
- Security: how quickly intrusions are discovered. The gap here is sobering: IBM’s Cost of a Data Breach Report 2025 found organizations took an average of 181 days to identify a breach and another 60 days to contain it, 241 days end to end, with the average breach costing $4.44 million.
The MTTD Formula (With a Worked Example)
MTTD is a simple average over a reporting period:
MTTD = total detection time across all incidents ÷ number of incidents
Detection time per incident = (time the incident was detected) − (time the failure actually began). The failure start time usually comes from postmortem reconstruction: log timestamps, metric inflection points, or the deploy that introduced the fault.
| Incident | Failure began | Detected | Detection time |
|---|---|---|---|
| Payment API errors | 02:10 | 02:14 | 4 min |
| Memory leak, search service | 09:00 | 10:30 | 90 min |
| Expired TLS certificate | 00:00 | 00:26 | 26 min |
MTTD = (4 + 90 + 26) ÷ 3 = 40 minutes.
Note how one slow-burning incident dominates the average. That is typical, and it is why teams should review the distribution and the outliers, not just the mean. A median MTTD of 5 minutes with two multi-hour outliers tells a very different story than a uniform 40 minutes, and the fix is different too.
MTTD vs MTTA vs MTTR vs MTBF
MTTD is one member of the incident metrics family, and each member covers a different slice of the timeline:
| Metric | Question it answers | Clock starts | Clock stops |
|---|---|---|---|
| MTTD | How fast do we notice failures? | Failure begins | Incident detected |
| MTTA | How fast does a responder engage? | Alert fires | Responder acknowledges |
| MTTR | How fast do we fully restore service? | Incident begins | Service verified healthy |
| MTBF | How often do failures occur? | One failure | The next failure |
The relationship to remember: MTTD is embedded inside MTTR. If your MTTR is 60 minutes and your MTTD is 40, then two-thirds of your incident duration is spent not knowing there is an incident. Teams that only optimize the repair phase often leave the larger share of downtime untouched. For the full family, including MTTF and how the metrics fit together, see our SRE metrics glossary.
Why MTTD Matters
- It caps everything downstream. No response process, however sharp, can start before detection. High MTTD makes every other metric look worse.
- It drives downtime cost. Undetected failures accumulate the same revenue loss and SLA burn as visible ones; see our breakdown of what downtime actually costs.
- It shapes customer trust. There is a meaningful difference between “we detected and fixed it before most users noticed” and “we found out from angry tweets.” Detection speed decides which story you tell in your incident communication.
- It reflects monitoring quality. MTTD is the most honest scorecard for your observability investment. Coverage gaps show up here first.
What Is a Good MTTD?
There is no universal benchmark, because detection speed depends on failure type: a hard crash should be caught in seconds, while a slow degradation legitimately takes longer. Useful reference points by maturity:
- Strong: under 5 minutes for availability failures on critical paths, driven by automated alerting on symptoms users feel (error rate, latency), not just resource thresholds.
- Typical: 10 to 30 minutes, with automated detection for crashes but blind spots on degradation and data issues.
- Needs work: hours, or incidents regularly reported by customers before monitoring notices. If support tickets are your detection system, MTTD is your first fix.
Set targets per severity tier rather than one global number: a SEV1 on the checkout path deserves a tighter detection budget than a SEV4 in a batch job.
How to Reduce MTTD
1. Monitor symptoms, not just causes
Alert on what users experience: error rates, latency percentiles, and failed transactions, following the four golden signals from the Google SRE book. Cause-based alerts (CPU, disk) miss failures that do not exhaust resources, which is exactly where long detection tails live. Understanding the difference is the core of observability vs monitoring.
2. Close coverage gaps deliberately
Every postmortem should ask: could we have detected this sooner, and what signal would have caught it? Turn each answer into a new check. Synthetic monitoring of critical user journeys and end-to-end server monitoring catch entire failure classes that internal metrics miss.
3. Cut alert noise so real signals surface
Paradoxically, over-alerting increases MTTD. When responders are drowning in false positives, the real alert gets skimmed past or sits unread. Reducing alert noise and deduplicating related alerts makes the genuine failure unmistakable.
4. Route detections to a human instantly
Detection is not complete until someone who can act knows about it. An alert that lands in an unwatched dashboard or email inbox has not really been detected. Reliable alert routing through on-call schedules and escalation policies, delivered to a fast mobile app, closes the last gap between machine detection and human response. This handoff is exactly what an on-call incident management platform like itoc360 is built for.
5. Track MTTD per service and review it
Make detection time a standing field in your postmortem template and a chart on your reliability dashboard alongside your other incident management KPIs. Teams that measure MTTD explicitly are the only ones that improve it.
Frequently Asked Questions
What does MTTD stand for?
MTTD stands for mean time to detect: the average time between the start of a failure and the moment it is discovered. In security contexts it is sometimes called MTTI, mean time to identify.
How is MTTD different from MTTA?
MTTD measures the gap from failure start to detection; MTTA measures the gap from alert to a responder acknowledging it. MTTD ends roughly where MTTA begins, and both happen before any repair work starts.
Is MTTD included in MTTR?
Yes. MTTR measured from incident start to full resolution includes detection time. A 40-minute MTTD inside a 60-minute MTTR means most of your incident duration is spent undetected, which makes detection the highest-leverage improvement.
What is a good MTTD benchmark?
For critical availability failures, mature teams detect in under 5 minutes through symptom-based automated alerting. If customers regularly report incidents before your monitoring does, treat that as the clearest signal that MTTD needs investment.
How do you measure MTTD in practice?
For each incident, establish the true failure start time during the postmortem using logs, metric history, or deploy timestamps, then subtract it from the detection timestamp. Average across incidents in the period, and review the median and outliers alongside the mean.