How to calculate mean time to detect from incident records

Three incidents took four, thirty-two and eleven minutes to find. The mean time to detect, or MTTD, is 15.7 minutes. Leave the thirty-two-minute incident off the report and the mean falls to 7.5. Nobody found a failure any sooner. To tell whether detection improved, you need the incident records beside the average.

For each included incident, subtract the onset time from the discovery time. Add those durations and divide by the number of incidents with usable durations. The detection clock stops at discovery. Keep acknowledgment and recovery separate so the report can show which part of the response changed.

Calculate the mean and keep the three rows

Use this illustrative record. The discovery method matters because the team may need to fix something different when an engineer or customer finds the problem first.

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

The median is eleven minutes and the range is four to thirty-two. With three incidents, the individual durations are more useful than a precise-looking percentile. An automated-only view would report four minutes for one observation. Label it that way and keep the broader view, which includes manually reported failures as AWS’s monitoring guidance recommends. The Atlassian incident metric reference provides the conventional discovery definition.

When you know discovery but only have a range for onset

Suppose the last confirmed healthy observation was at 10:00. A failed request was logged at 10:06 but only found in the later review. The team discovered the failure at 10:10. If the healthy and failed observations bracket the start of one sustained failure, the onset falls between 10:00 and 10:06 and detection took between four and ten minutes. Reporting four chooses the latest onset the evidence supports.

Uncertain onset creates a duration range

Read diagram description

The service was last observed healthy at 10:00. A failed request was logged at 10:06 and found retrospectively. The team discovered the failure at 10:10. Under the sustained-failure assumption, choosing a four-minute detection duration uses the latest onset the observations support.

Check that the observations describe the same operation and the same failure. Intermittent errors can break the assumption that the service stayed impaired between those points. The first unusual metric can precede user impact or have another cause. If it is your best proxy for the start, name it and explain the uncertainty.

Decide what discovery means in your report too. The detector firing and the notification reaching a responder are different moments. A customer may notice a problem before filing a report. Retain the useful timestamps, choose the endpoint you can define consistently, and account for time zones, clock skew and delayed ingestion before subtracting them. Preserve a supported range or state the estimation rule. If onset is unknown, count the incident as missing a usable duration and explain why. Assigning zero would make the gap look like immediate detection.

Report who found the incidents, including customers

Imagine two long incidents that monitoring missed and customers eventually reported. Adding those incidents can raise the average by making the reporting more complete. Leaving them out can make automated discovery look fast while concealing exactly where it failed. Keep the number of eligible incidents, the number timed and the discovery routes visible. An untimed customer report can still expose a monitoring gap.

Compare similar services, severities and failure types when you have enough examples. A five-minute target has different consequences for a slow capacity problem and a failed critical transaction. Start from how soon a responder could still make a useful difference.

Open the thirty-two-minute record

Ask what evidence was available before the engineer noticed the problem. If nobody was observing a failed user journey, a synthetic check might find it sooner. If the evidence already reached the team but they spent the time after discovery looking for an owner, fix that response path instead. Anomaly detection is another option when it can find relevant deviations. Check what it misses and how many false investigations it creates before replacing a simple threshold.

The companion article on MTTD and response delay follows the waits after discovery. Measure whichever delay you are trying to reduce, and check whether acting sooner would have changed the outcome.

Where the other clocks start

Mean time to acknowledge, or MTTA, usually runs from an alert or notification to acknowledgment. MTTR can refer to time to repair, recover, resolve or respond. In one illustrative incident, impact starts at 10:00, the alert detects it at 10:04, a responder acknowledges it at 10:06 and the service recovers at 10:25. Detection took four minutes and acknowledgment took two after the alert. Recovery was twenty-five minutes from impact or twenty-one from discovery. Each is a duration for one incident. State the endpoints and population before comparing averages.

If your team uses “mean time to identify,” record whether it ends at discovery or at identifying a cause. Put that definition in the SRE KPI scorecard, and use the guide to reducing incident response delays with AIOps if the evidence points to a later wait. When the next report comes out, look for the thirty-two-minute case. You want to see how it was found sooner, or what you learned from it, before its absence makes the new number look better.