MTTR and MTBF: Formulas, Targets and Pitfalls

MTTR is the average time between an incident starting and the service being usable again. MTBF is the average gap between those incidents. Together the pair describes reliability from two directions: how often you break, and how long you stay broken. Both are simple divisions, and both are easy to report dishonestly.

What do the two metrics actually measure?

One measures recovery, the other measures the quiet stretch in between. The acronym is genuinely ambiguous, and Atlassian's reference page lists four expansions in active use: mean time to repair, to recover, to respond and to resolve. Pick one, write the definition down, and stop relitigating it in every review.

Metric	Expansion	Clock starts	Clock stops
MTTD	Mean time to detect	the failure begins	something notices
MTTA	Mean time to acknowledge	the alert fires	a human picks it up
MTTR	Mean time to recovery	the failure begins	service is usable again
MTBF	Mean time between failures	service recovers	the next failure begins

We prefer mean time to recovery, counted from the first failed request rather than from the alert. It is the only version that matches what a user actually sat through, and it refuses to hide a slow detector inside a flattering number.

How is MTTR calculated?

Divide total downtime by the number of incidents over a fixed window. Three outages in a month totalling six hours gives two hours. IBM's definition uses the same arithmetic, and so does every page-one result for the term.

MTTR  = total downtime / number of incidents
MTBF  = total operating time / number of failures
MTTD  = time from first failed request to first alert

The arithmetic is not the hard part. Deciding when the clock starts is, and that decision belongs in the same document as your incident severity levels.

Why MTBF is the harder number

MTBF needs a long sample to mean anything. Two failures in a quarter give you one interval, and one interval is an anecdote rather than an average. Splunk's write-up makes the related point that a single bad month can dominate a small dataset completely.

That is a retention problem before it is a statistics problem. History keeps p50, p95 and p99 per monitor for one month on the free plan, a year on Individual and two years on Enterprise as of September 2026. A year of samples is roughly the minimum for a quarterly MTBF you would defend in front of a customer.

The slice you can fix this afternoon

Detection sits inside your recovery time, and it is usually the largest component nobody owns. If a check runs every five minutes, the expected blind period before anyone knows is two and a half minutes. That delay is added to every single incident, before a human is even involved.

Check interval	Average detection delay	Added to every incident
5 minutes	2.5 minutes	yes
1 minute (free plan)	30 seconds	yes
30 seconds (paid plans)	15 seconds	yes

Tightening the interval is the cheapest MTTR reduction available, and it needs no process change. The trade is noise, which is why confirmation from a second region matters: a blip seen from one probe should not start the clock at all. Region codes and probe egress IPs are listed on the probe IPs page.

Common mistakes with these numbers

Averaging incidents of wildly different severity. A 30-second blip and a four-hour database outage in the same mean produces a figure that describes neither. Bucket by severity first, then divide.

Treating planned work as a failure. Announced work belongs outside the calculation, provided it was announced before it started. That rule is worth writing into your maintenance window policy rather than deciding case by case.

Optimising the metric instead of the service. A team that closes incidents early gets a beautiful MTTR and an ugly reputation. Pair it with the four golden signals so latency and error rate keep the summary metric honest.

A useful MTTR is one number in a set: detection, acknowledgement, recovery, and the interval between failures. Measure all four, date them, and keep enough history to see the trend rather than the last bad week. You can start the detection half on the free plan with 10 monitors at a one-minute interval as of September 2026, then open an account and watch the numbers settle.