What Is MTTD (Mean Time to Detect)?

Last verified on Nov 8, 2026.

You cannot fix what nobody knows is broken. MTTD measures that gap: how long a problem exists before something notices it. It is the first slice of every incident timeline, and often the one a team can shrink most cheaply.

Definition

NIST's glossary defines mean time to detect as a metric that tracks the average amount of time that a problem exists before it is found. The IEC's electrotechnical vocabulary has a close cousin in reliability engineering, fault detection time: the interval between a failure and the detection of the resulting fault.

Both definitions start the clock at the failure, not at the alert. That sounds obvious, but it is easy to get wrong, because the failure's real start time is rarely recorded anywhere. It has to be reconstructed.

MTTD = sum of (detected_at - impact_started_at) for every incident / number of incidents

Finding the True Start

For each incident, work out when the problem began from the data:

• The first error log or the first failed health check after a bad deploy.
• The moment an SLI crossed its threshold, from a time series.
• The deploy or config change timestamp, when the failure started at once.
• A customer's first report, if that is when you first knew. In that case detection is late by definition.

With request logs you can find the onset as the first minute the error rate exceeded your threshold. This assumes a table request_logs(ts, status) and an incidents(id, window_start, window_end, alert_fired_at) table:

-- First minute with more than 5% server errors inside each incident window
WITH per_minute AS (
  SELECT i.id AS incident_id,
         date_trunc('minute', r.ts) AS minute,
         count(*) FILTER (WHERE r.status >= 500)::float / count(*) AS error_rate
  FROM incidents i
  JOIN request_logs r ON r.ts BETWEEN i.window_start AND i.window_end
  GROUP BY 1, 2
),
onset AS (
  SELECT incident_id, min(minute) AS impact_started_at
  FROM per_minute
  WHERE error_rate > 0.05
  GROUP BY 1
)
SELECT avg(i.alert_fired_at - o.impact_started_at) AS mttd
FROM incidents i
JOIN onset o ON o.incident_id = i.id;

Choose the same threshold every time, or the number will move with your definition and not with your detection.

The Alerting Attributes Behind It

Google's SRE workbook lists four attributes to weigh in any alerting strategy:

• Precision: the proportion of detected events that were significant.
• Recall: the proportion of significant events that were detected.
• Detection time: how long it takes to send notifications in various conditions. The workbook notes long detection times can hurt the error budget.
• Reset time: how long alerts keep firing after an issue is resolved.

MTTD is the measured outcome of the third. The four pull against each other: a short window detects sooner and fires on noise. The workbook's answer is multiwindow, multi-burn-rate alerting, where a fast burn pages within minutes and a slow burn opens a ticket days later. That fits detection time to severity. See the error budget page for its recommended thresholds.

What Cuts It

• Alert on symptoms. The SRE book separates what is broken from why. Alerting on user-visible failures such as errors and slowness catches problems whatever their cause. A rule per cause only catches the causes you thought of.
• Keep paging rules simple. The same chapter says rules that wake humans should be simple to understand and represent a clear failure.
• Cover the silent failures. Wrong content with a 200 status, jobs that never ran, and stale data show up in no error rate. See missed schedules, stale data, and latency spikes.
• Cover what no rule anticipates. New error types appear in logs without matching any rule you wrote. Sazabi's reliability issue detection watches for new kinds of errors, with no alert rule to write.

Pitfalls

• Survivorship. Incidents that customers reported first get recorded with a late detection time, or left out. Count them separately: the share of incidents found by customers first is a strong complement to the average.
• Mean over a few incidents. One slow detection dominates. Use the median and a high percentile, as the MTTR page explains.
• Mixing definitions. MTTD, MTTA and MTTR cover successive slices of one timeline. Keep each slice's start and end events written down.