Calculating mean time to detect from incident records

Mean time to detect, or MTTD, averages the time from a failure’s onset to its discovery. The number can fall for two very different reasons: the team found failures sooner, or the report stopped counting the awkward ones. Keep the incident rows beside the average so you can tell which happened.

Discovery ends this measurement. Acknowledgment, investigation and recovery follow their own clocks, sometimes with work overlapping. A monitoring improvement should not have to explain a later wait for someone authorized to act. The three-incident record below shows how to separate those questions before interpreting the average.

Three incidents produce a 15.7-minute mean

The following illustrative record measures onset to discovery for three incidents. It retains the discovery method because a monitoring event, an engineer's observation and a customer report describe different paths by which a failure became known.

MTTD = (4 + 32 + 11) / 3
     = 15.666… minutes
     ≈ 15.7 minutes

The three durations total 47 minutes, producing a mean of approximately 15.7 minutes. The median is 11 minutes and the range is 4–32 minutes. With just three incidents, examining those cases is more informative than presenting a finely calculated percentile. The Atlassian metric reference supplies the conventional detection definition.

Removing incident B from this illustrative record would change the result to (4 + 11) ÷ 2 = 7.5 minutes, although neither remaining detection became faster. A monitoring-only view would retain just incident A and report four minutes for one observation. Those can be useful subsets, but their labels and counts must distinguish them from the three-incident report. AWS’s monitoring guidance includes manual reports alongside automated discovery.

The 32-minute row is where the average becomes useful. What evidence was available while the failure went unnoticed, and who or what could have seen it? That question leads to an investigation. Rounding 15.666 to another decimal place does not.

An uncertain start produces a range

Onset should represent the failure condition being measured, using the best available evidence. The first anomalous metric can be a proxy, but an anomaly may precede user impact or be unrelated to it. Name the proxy and its uncertainty rather than calling it an exact start.

Discovery needs a definition too. A detector can fire before its notification reaches the responder, and a customer can notice a failure before opening a support request. Decide which recorded event starts or ends each interval and retain the other useful timestamps. Normalize time zones and examine clock skew or delayed ingestion before comparing them; a precise subtraction is only as meaningful as the events being subtracted.

Some incidents have no defensible onset timestamp. Mark that uncertainty or analyze a separate population; a precise guessed value makes comparisons cleaner while making the conclusion less trustworthy.

An onset interval may be more defensible than a point when the observations bracket the start of one sustained failure. In an illustrative case, the last confirmed healthy observation is at 10:00, a failed request recorded at 10:06 is found during the later incident review, and discovery occurred at 10:10. With those assumptions, detection took between four and ten minutes. Intermittent failures or observations of different operations would not establish the same onset interval. Reporting exactly four selects the latest possible onset, so it should be identified as an estimation choice rather than the only result supported by the record.

Uncertain onset creates a duration range

Read diagram description

Illustrative observations bracketing one sustained failure: last confirmed healthy at 10:00, failed request recorded at 10:06 and found retrospectively, discovery at 10:10. Under these assumptions, detection took between four and ten minutes; reporting only four chooses the latest possible onset.

Keep the interval or disclose the estimation rule. Otherwise a change in observation frequency could alter reported MTTD without an equivalent change in detection. Unknown onset should not become zero; show how many incidents lack usable timestamps and why they are excluded.

The missing durations also raise a population question: which incidents remain visible in the report? A failure first reported by a customer still tells the team something about monitoring, even when its onset cannot be timed precisely.

Customer reports belong in the detection population

Consider a hypothetical month in which monitoring misses two long incidents that customers eventually report. Removing them from the calculation makes automated discovery appear faster while omitting consequential coverage gaps. Keep the discovery routes visible and explain missing timestamps instead of letting the denominator hide those failures.

Adding eligible customer-reported cases may make measured MTTD rise. That increase can reflect more complete reporting of previously invisible failures rather than deteriorating detection. Preserve enough context to distinguish those explanations before interpreting the trend.

Where sample size permits, compare similar severity, service and failure populations. A universal five-minute target says little without evidence that it fits the consequences and available intervention time. A slow capacity warning and a failed critical transaction can leave different windows for useful action.

What the 32-minute case can reveal

Trace one slow-detected incident to the observable signal, when it became available and what earlier discovery would have enabled. A synthetic check might reveal a failed user journey sooner. Better ownership might instead improve action after discovery. The timeline establishes which change addresses the observed constraint.

Anomaly detection may help identify deviations, but it also needs evaluation for false-alert cost and coverage on known failures before replacing a threshold. There is no requirement to optimize detection before recovery. Choose the interval with the strongest evidence of avoidable harm.

The companion article on MTTD and response delay explores the post-discovery side. Used together, the intervals should explain a decision the team can improve rather than compete for the most flattering number.

Where MTTD ends and response timing begins

MTTD measures discovery. Mean time to acknowledge, or MTTA, usually starts at an alert or notification and ends at acknowledgment. MTTR is less consistent: teams use it for repair, recovery, resolution or response. State the endpoints rather than assuming the acronym makes two reports comparable.

In an illustrative incident, impact starts at 10:00, detection occurs at 10:04, acknowledgment at 10:06 and recovery at 10:25. Detection took four minutes; acknowledgment took two after detection. Recovery took 25 minutes from impact or 21 from detection. Both recovery durations are understandable once their start is stated. A single incident contributes a duration, while a mean requires the population.

“Mean time to identify” may refer to discovery or identifying a cause later in the response. Record which event it measures in the SRE KPI scorecard, then use the guide to reducing incident response delays with AIOps to select an intervention.

Keep 15.7 minutes as the signpost, not the destination. It points back to the 32-minute investigation; an excluded customer report points toward a different question about coverage. Both can lead to better detection, but they are not the same repair. A lower number is worth celebrating when the incident record shows what actually improved.