Detection took a minute. What filled the next twenty?

At 10:03, the alert arrives. Someone looking at the detection chart later could quite reasonably say, “That was quick.” Someone trying to use the service at 10:20 would have a different observation: it still is not working normally.

Both fit this illustrative incident. Monitoring found the slowdown in one minute; customers then waited twenty more for recovery. To make the next incident shorter, we need to know what happened during those twenty minutes, not ask the detection number to explain time it never counted.

One minute to find it, twenty more to recover

Here is the whole hypothetical sequence. Latency means how long a request takes; the first line marks the point at which that delay crosses the threshold chosen for this incident.

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 first two lines give us one minute to detection. Average that interval across the incidents being counted and we have mean time to detect, or MTTD. A single incident contributes one duration; it does not, by itself, give us a mean.

Notice where that clock stops. The responder has not yet acknowledged the page, let alone made a change. A mitigation is an action intended to reduce the impact; even applying it at 10:18 does not mean customers have recovered at that instant. Their normal service returns at 10:23. Atlassian's incident-metric definitions distinguish discovery from the later response and recovery. Teams still need to agree what establishes onset and discovery in their own records.

Our responsible team starts investigating at 10:11: eight minutes after detection, nine after onset. Recovery takes another twelve minutes, for twenty-one overall. Calling those first nine minutes “detection” would hide the wait for the right investigator inside the wrong number.

The alert arrives near the start of the incident

Read the timeline in words

In this illustrative incident, detection takes one minute. Investigation begins eight minutes after detection, nine minutes after onset. The full onset-to-recovery interval is 21 minutes. A mean requires durations from the incidents included in the calculation.

What was happening between 10:05 and 10:11?

The responder acknowledged the page at 10:05. The responsible team began investigating at 10:11. Six minutes sit between those entries, neatly measured and not yet explained.

Perhaps the page reached someone already handling another incident. Perhaps that person was finding the owner of a dependency, a service this one relies on. Or perhaps they were checking whether undoing a recent change could damage data. The same six-minute gap can contain very different work.

This is where the responder belongs in the review, beside the timeline rather than underneath its verdict. Read the record together. Did the page say which operation was failing? Did it reach a rotation with someone available? Could that person open the view needed to tell likely causes apart? A quiet incident channel may omit a call to another team, a check of an affected account or an arrangement for someone else to cover. Missing messages cannot establish that nothing happened.

The answer changes the repair. If the page went to the wrong team, improve its route. If an expired permission blocked the investigation, restore it and rehearse the check. If repeated pages offered no useful action, review the alerts. An AI summary might make the account easier to read, but eloquence will not open the dashboard the responder could not access.

Some of those six minutes may also have been well spent. Checking whether a difficult-to-reverse change will damage data costs time; skipping that check can cost much more. The useful distinction is between time spent answering a necessary question and time spent hunting for information or access that should already be available. Shortening the second kind need not rush the first.

Who made it into the average?

Now put this incident beside the others in a monthly report. If the list contains only failures found by monitoring, the ones customers discovered are absent. The calculation may be correct for its list while missing exactly the failures that deserve attention.

The mixture matters, too. Add many minor incidents that are easy to detect and the mean can fall even if severe failures remain just as hard to find. A better number has not necessarily bought a better experience.

Keep the incident count, severity mix and inclusion rule with the comparison. Then check what started each clock. A record reaching a collector, the service that receives monitoring data, is not necessarily the moment the underlying event occurred. When onset is uncertain, an explained estimate is more useful than a precise timestamp standing in for knowledge nobody has. The MTTD calculation guide develops those measurement choices.

Put the improvement where the wait was

Suppose several reviews reveal the same detour: the page arrives promptly, then someone has to find the team able to investigate. Saving thirty seconds in detection would still help, but it would leave that larger detour in place. Test the route to the right rotation and check that the person receiving it can begin the investigation.

A different recurring wait calls for different work. Put a frequently needed dependency view within reach. Rehearse a rollback with the on-call person's actual permissions if access keeps delaying it. An AI-generated explanation can help gather the context, provided it links to the underlying records and includes observations that challenge its account, not only those that make the story tidy.

After the change, look again at the interval you intended to shorten and the decisions made within it. A team reaching the wrong explanation faster has improved a timestamp without helping the customer at 10:20.

Better routing belongs in detection-to-investigation time. A rehearsed rollback that restores service sooner belongs later in the sequence. Keep those improvements where they happened, and the one-minute detection result becomes useful again: a small, accurate part of an account that follows the customer all the way to 10:23.