What MTTD misses between the alert and the response

In an illustrative incident, the alert arrives one minute after latency starts rising. Twenty minutes later, users can finally complete their work normally. Both statements can be true, and the space between them is where a useful incident review begins. A fast detection result tells the team something important, but it has not yet explained the response.

Imagine spending the next sprint making the alert arrive thirty seconds sooner when the page already sits with the wrong team for eight minutes. The detection metric would improve, but most of the lost time would remain. The useful question is where the response actually waited: before discovery, while finding an owner, during investigation or while restoring the service.

Where MTTD stops on the timeline

Mean time to detect, or MTTD, averages the interval from incident onset to discovery. It ordinarily ends before mitigation reduces the impact and before the user-facing service recovers. Atlassian’s incident metric definitions distinguish those events, though the team still needs local definitions of onset and discovery to make its own records comparable.

Consider this hypothetical latency incident. Monitoring finds the condition promptly, but the page does not identify the team equipped to investigate it:

10:02  Latency first crosses the incident threshold
10:03  Monitoring detects the condition and sends an alert
10:05  Responder acknowledges the page
10:11  Investigation begins with the responsible team
10:18  A mitigation is applied
10:23  User-facing performance recovers

The detection duration is one minute. Another eight minutes elapse before the responsible team begins investigating, so onset to investigation is nine minutes. Twelve more minutes pass before recovery. Calling the nine-minute interval MTTD would erase the distinction between seeing the problem and getting useful investigation underway. And because this is one incident, its one-minute duration is an input to a mean, not a mean by itself.

Detection is only the first interval

Read diagram description

Illustrative incident: detection takes one minute; investigation starts eight minutes after detection. The full onset-to-recovery interval is 21 minutes. One incident is not a mean.

What happened between acknowledgment and investigation?

Six minutes separate acknowledgment from investigation, and the chart is silent about what filled them. Perhaps the responder was arranging coverage for another incident, checking whether rollback would damage data, or finding the only team authorized to change a dependency. Those are different problems hiding in the same blank space. The timestamp tells you where to ask; it does not supply the answer.

Go back to what the responder could see and do at the time. Did the page name the affected operation and reach a staffed rotation? Did the runbook’s first check separate plausible causes? A conversation with the responder and the supporting record can establish those conditions. A line on the chart cannot explain their motive for waiting.

Separating detection from response shows which condition kept a credible page from producing a useful action. Wrong ownership calls for routing work. Expired access calls for a permission repair and rehearsal. Recurring non-actionable pages call for alert review. Generating a more confident summary would not remove any of those particular obstacles.

Some investigation time protects the service. A high-impact action that is difficult to reverse may deserve additional checking; the improvement target is avoidable uncertainty rather than the shortest possible interval. A review should distinguish necessary evidence gathering from work the system needlessly forced a responder to repeat.

There may be work outside the main channel: checking an affected account, finding coverage, or contacting the dependency owner. Use the record to explain the part it can explain, and leave the rest open. Filling the silence with an assumption about the responder turns an accurate timeline into an unfair staffing story.

Which incidents made it into the average?

The average has another blind spot: it can only describe the incidents admitted to the calculation. A report limited to automatically detected incidents omits failures found by customers or later investigation. Add many easy-to-detect minor cases and the mean can fall even while severe failures remain just as hard to find. Keep population, severity mix and sample size beside the comparison, so a change in the incident mix cannot masquerade as better detection.

Even onset may be an estimate. A timestamp can record arrival at a collector rather than the underlying event. An estimated interval with its supporting evidence is more honest and useful than a precise-looking value the record cannot justify. The MTTD calculation guide develops these measurement choices without folding them into the separate question of response delay.

Different delays call for different repairs

Compare a few incidents and look for the obstacle that returns. If pages repeatedly land with the wrong owner, test the routing repair. If everyone pauses at the same dependency question, put that view where the responder can reach it. If rollback requires access the rotation does not have, rehearse with the actual on-call permissions. Each change should address the delay you found, rather than simply make the detection number more attractive.

If AI assembles that context, its links to underlying signals and contradictory evidence let responders judge the proposed explanation. After the change, revisit the interval it was intended to improve and examine the resulting decisions as well as elapsed time. Choosing a wrong hypothesis sooner would shorten a chart without resolving the original problem.

If better routing gets the latency page to the responsible team sooner, the improvement belongs in detection-to-investigation time. If a rehearsed rollback restores service faster, it belongs later in the timeline. Keeping those changes separate makes a good MTTD result useful without asking it to describe recovery work outside its clock.