MTTR Calculator (SRE)

Mean Time to Resolve, in context

MTTR is the average elapsed time between the moment an incident is detected and the moment service is fully restored, measured across a set of incidents. It is the metric incident reviews reach for first because it answers a direct operational question: once something breaks and the team knows about it, how long does recovery usually take? The MTTR calculator above derives that figure from a raw incident log, alongside three related measures that are easy to confuse with it.

The acronym itself is ambiguous, and the ambiguity matters. The same four letters stand for Mean Time to Repair, to Resolve, to Recovery, and to Respond, and those are not the same clock. Repair and resolve usually run from detection to full restoration; respond runs only to the start of human action; recovery sometimes extends through post-incident verification. Whenever an MTTR figure is quoted, the first thing to settle is which clock it counts, because two teams both reporting "45 minutes" may be measuring different intervals entirely.

The detection half is tracked separately as MTTD, Mean Time to Detect — the gap between when an incident actually began and when an alert fired or a human noticed. MTTF, Mean Time to Failure, measures the healthy interval between the end of one incident and the start of the next, while MTBF folds incident duration back in. Keeping detection and recovery on separate axes is precisely what lets a team tell whether its real problem is finding incidents or fixing them.

How the number is calculated

The core calculation is a plain arithmetic mean: MTTR = total resolution time across all incidents / number of incidents. Each incident contributes one resolution interval, measured from its detection timestamp to its resolved timestamp; the tool sums those intervals and divides by the incident count. Detection time is deliberately excluded from that interval and reported on its own as MTTD (total detection delay / number of incidents), so a slow alerting pipeline does not silently inflate what then looks like a repair problem.

Because the inputs are timestamps rather than pre-summed durations, the arithmetic is sensitive to data hygiene. Out-of-order timestamps, missing timezones, or a detected time that precedes the start time will distort the mean or be rejected outright. The calculation is deterministic — identical input always produces identical output — which makes it well suited to tracking the same metric across review periods, as long as the logging convention stays constant between them.

Twelve incidents over a quarter

Suppose a service recorded twelve incidents in a quarter, and the total restore time across all of them — each measured from detection to resolution — came to 540 minutes. The mean time to resolve is 540 / 12 = 45 minutes. That is the headline MTTR for the quarter: when this service broke and the team was aware of it, recovery took three-quarters of an hour on average.

Operationally, a 45-minute average lands in strong territory, under the one-hour mark that the DORA research associates with elite recovery. But the average alone hides the shape of the distribution. Those twelve incidents could each have sat close to 45 minutes, or eleven could have been 20-minute blips with a single five-hour outage dragging the mean upward. The two situations demand very different responses, which is why the average should always be read next to the median and the slowest single incident, never on its own.

What a given MTTR implies

As a rough orientation drawn from the DORA reliability bands: a mean recovery under one hour is generally considered elite, under a day is strong, under a week is middling, and beyond a week points to a structural recovery problem rather than a tuning issue. The tool tags a result against these bands, but they are reference points, not targets. The right MTTR for any service depends on what it does and what its users tolerate; an internal batch job and a payments API should not be held to the same recovery standard.

The more actionable read comes from comparing MTTD against MTTR. If detection time dominates, the bottleneck is observability: the team loses most of the clock before anyone even knows there is a problem, and faster repairs will barely move total downtime. If repair time dominates, the bottleneck is the response process itself — runbooks, escalation paths, access, and tooling. The same headline MTTR can call for opposite investments depending on which half is larger, so the split is worth more than the single number.

When MTTR is misleading

MTTR is a mean, and means are fragile on the skewed, long-tailed data that incidents produce. A single multi-hour outage among many short ones can pull the average well above what a typical recovery actually looks like, so a falling MTTR is not always good news and a rising one is not always bad — both can be artifacts of one unusual incident. Reporting the median and the 90th-percentile recovery time alongside the mean gives a far more honest picture of the lived experience.

Three other traps recur. Small samples are noisy: an MTTR over five incidents can swing wildly when the sixth arrives, so short windows are indicative rather than precise. The definition of "resolved" has to be consistent — if some incidents are stamped at mitigation and others at full root-cause closure, the figures are not comparable. And MTTR says nothing about how often incidents happen; a team with an excellent MTTR but a high incident rate can still be delivering poor reliability, which is why this metric belongs beside frequency and detection figures rather than standing alone.