What Is MTTR? Mean Time to Recovery, MTTD and MTBF Explained

MTTR, or mean time to recovery, is the average time between a service failing and that service working again for users. The formula is simple: add up the downtime of every incident in a period and divide by the number of incidents. Three incidents that lasted 10, 20 and 60 minutes give an MTTR of 30 minutes. Because MTTR includes the time before anyone even knows something is wrong, the fastest way to lower it is often not faster fixes but faster detection.

The four metrics and what each one measures

Every incident follows the same timeline. Each metric measures a different slice of it.

failure starts --> detected/alerted --> acknowledged --> service restored --> next failure
|---- MTTD ----|
               |----- MTTA -----|
|------------------------ MTTR -------------------------|
                                                        |------ MTBF (uptime) ------|

A note on the "R"

Teams use MTTR for mean time to repair, recovery, restore, respond and resolve. They are not the same:

• Recovery / restore: from the start of the failure until users are served normally again. This is the version used in this article, and the one that matches what customers experience.
• Repair: sometimes only the hands-on fix time, excluding detection.
• Respond: sometimes the time until someone starts working on it, which overlaps with MTTA.
• Resolve: often includes follow-up work such as a root-cause fix, so it can be much longer than the outage itself.

None of these is wrong. What matters is that you define your version once, write it down, and measure every incident the same way. Comparing your "repair" number with someone else's "recovery" number tells you nothing.

The formulas

MTTD = sum of (detection time - failure start) / number of incidents
MTTA = sum of (acknowledgment time - alert time) / number of incidents
MTTR = sum of (restore time - failure start) / number of incidents
MTBF = total operating time (uptime) / number of failures
Availability = MTBF / (MTBF + MTTR)

The last line ties these metrics to the uptime percentage you report. Over a full period, MTBF + MTTR equals the average length of one up-then-down cycle, so the ratio is the share of time the service was up. For how those percentages translate into minutes, see uptime percentage explained.

A worked example

Suppose a web app had four incidents in a 30-day month. Times are in minutes after each failure started.

MTTD. Detection times are 6, 4, 12 and 2 minutes. (6 + 4 + 12 + 2) / 4 = 24 / 4 = 6 minutes.

MTTA. Time from alert to acknowledgment: 10 - 6 = 4, 7 - 4 = 3, 20 - 12 = 8, 5 - 2 = 3. (4 + 3 + 8 + 3) / 4 = 18 / 4 = 4.5 minutes.

MTTR. Total downtime is 46 + 25 + 88 + 21 = 180 minutes. 180 / 4 = 45 minutes.

MTBF. A 30-day month has 30 x 24 x 60 = 43,200 minutes. Subtract the 180 minutes of downtime and the service was up for 43,020 minutes. 43,020 / 4 = 10,755 minutes, about 179.3 hours or 7.5 days between failures.

Availability. 10,755 / (10,755 + 45) = 10,755 / 10,800 = 99.583%. As a check, 43,020 / 43,200 gives the same 99.583%.

Where the time actually went

Break incident 3 down: 12 minutes passed before anyone was alerted, 8 more before someone picked it up, and 68 minutes went into diagnosis and the fix. Across all four incidents, detection plus acknowledgment account for 24 + 18 = 42 of the 180 minutes, nearly a quarter of all downtime, before any repair work started.

How faster detection lowers MTTR

MTTR is a sum of phases, so shortening any phase shortens MTTR by the same amount. Detection is usually the easiest phase to improve, because it is mostly a configuration choice rather than an engineering project.

With a scheduled external check, the delay before a failure is noticed depends on the check interval. The failure can begin at any moment between two checks, so on average you wait half an interval for the next one, plus the time to confirm the failure before alerting:

Add a confirmation re-check (to avoid alerting on a single network blip) and alert delivery, and a one-minute interval typically detects a hard outage within one to two minutes.

Apply that to the example. If every incident had been detected in 2 minutes, detection would have dropped from 6, 4, 12 and 2 minutes to 2 minutes each, saving 4 + 2 + 10 + 0 = 16 minutes. Total downtime falls from 180 to 164 minutes and MTTR from 45 to 41 minutes, without changing anything about how the team fixes problems.

The bigger win is the incidents that a scheduled check catches but nobody else would have, such as a failure at 3 a.m. or on a page few people visit. Without monitoring, detection time for those is "whenever a customer complains", which can be hours.

PingRobot runs HTTP, keyword, TCP port and heartbeat checks every minute on the Pro plan (every 5 minutes on Free), re-checks failures from a second region, and alerts by email and signed webhooks, with Slack and Discord on Pro.

Lowering the other phases

MTTA: make alerts reach a person who can act

• Send alerts where people actually look. An inbox that nobody reads at night does not acknowledge anything.
• Keep alerts rare and accurate. Teams that receive frequent false alarms learn to ignore them, and MTTA grows.
• Decide in advance who owns which service, so nobody waits for someone else to pick it up.

Repair time: make the fix fast and boring

• Know what changed. Many incidents follow a deploy or configuration change. A deploy log and a one-command rollback cut diagnosis time sharply.
• Write short runbooks for failures you have seen before: where the logs are, how to restart the service, how to roll back.
• Monitor the specific layer. A keyword monitor that fails on a database error message, or a TCP port monitor on the database, points you to the cause instead of only telling you "the site is down".
• Use a checklist. When the cause is not obvious, work through layers in order, as in the website down checklist.

MTBF: fail less often

MTBF improves when you fix root causes, add capacity headroom, test changes before release and remove single points of failure. These are longer projects, which is why most teams see faster results by working on MTTD and MTTA first.

Common mistakes when measuring MTTR

• Starting the clock at the alert. That leaves out detection time and makes MTTR look better than what customers felt. Start at the first failed check or the first error in your logs.
• Mixing definitions. Measuring some incidents to "repaired" and others to "resolved" makes the trend meaningless.
• Ignoring partial outages. A checkout that fails for half of users is an incident even if the home page works. Decide which partial failures count.
• Trusting one number. With only a few incidents, a single long outage dominates the average. Report the count of incidents, the mean, the median and the longest one together.

Quick reference

• MTTR = total downtime / number of incidents
• MTTD and MTTA are parts of MTTR; shrink them and MTTR shrinks by the same amount
• MTBF = total uptime / number of failures
• Availability = MTBF / (MTBF + MTTR)
• For service-level targets built on these numbers, see SLA vs SLO vs SLI

Start monitoring free — 10 monitors, no credit card.