MTTR / MTBF Calculator

Two numbers that together describe reliability

With 120 minutes of total downtime across 4 incidents over 43,200 minutes of uptime, the MTTR is 30 minutes, the MTBF is 10,800 minutes — about 7.5 days — and the implied availability is 99.72%.

These two measures answer different questions. MTBF asks how often things break. MTTR asks how long they stay broken. Availability falls out of the relationship between them, and improving either one improves it.

The calculations

MTTR = total downtime ÷ number of incidents 120 ÷ 4 = 30 minutes to recover, on average.

MTBF = total uptime ÷ number of incidents 43,200 ÷ 4 = 10,800 minutes, or roughly 7.5 days between failures.

Availability = MTBF ÷ (MTBF + MTTR) 10,800 ÷ (10,800 + 30) = 99.72%.

That last formula is worth sitting with, because it shows the two levers are not equivalent in effort. Halving MTTR from 30 to 15 minutes lifts availability to 99.86%. Doubling MTBF to 21,600 minutes lifts it to 99.86% as well — arithmetically identical, but in practice halving recovery time is usually far cheaper than halving the failure rate.

That asymmetry is the central insight of modern operations practice. Preventing all failure is impossible; recovering fast is an engineering problem with known solutions — good alerting, runbooks, automated rollback, feature flags, and practice.

What MTTR actually includes

The acronym is used loosely, and the distinctions matter when comparing teams or tracking improvement:

Mean Time To Detect — failure begins until someone or something notices. Frequently the largest component, and the one most improvable by better alerting.

Mean Time To Acknowledge — detection until a human engages.

Mean Time To Repair — engagement until the fix is applied.

Mean Time To Recover — failure begins until service is fully restored. This is the one that matters to users and the one this calculator computes.

A team reporting a 10-minute MTTR measured from engineer engagement, against a team reporting 30 minutes measured from failure onset, may well have the worse user experience.

Why the mean is a weak statistic here

Incident durations are heavily skewed. Three incidents resolved in five minutes and one taking 105 minutes produce the same 30-minute mean as four incidents of 30 minutes each, and the two situations call for completely different responses.

Tracking the median and the 95th percentile alongside the mean gives a much truer picture. The long tail is usually where the real operational risk lives, and the mean is precisely the statistic that hides it.

Small incident counts are also unstable: with four incidents, one unusual event moves the mean by a quarter. Treat short-window figures as indicative rather than precise.

Reading the result

The availability figure here is derived from your incident data, which makes it a backward-looking measure of what happened. An SLO is a forward-looking target. They should be compared — if measured availability consistently sits below the SLO, either the target or the architecture needs to change.

Note also that this treats all downtime as equal. Thirty minutes at 4 a.m. on a Sunday and thirty minutes during peak trading are identical here and are not identical to the business. Weighting incidents by affected users or by traffic at the time gives a more honest picture.

Common mistakes

Optimising MTBF alone. Chasing zero failures is expensive and ultimately futile; fast recovery is the better investment.

Measuring MTTR from the wrong start point. Detection delay is part of the user's outage whether or not it is part of your metric.

Reporting only the mean. The tail is where the risk is.

Counting every alert as an incident. Inconsistent incident definition makes MTBF meaningless across periods.

Ignoring partial degradation. A service at 50% capacity is neither up nor down, and binary incident counting cannot represent it.