What is MTTR? Mean time to recovery, explained

MTTR is the average time it takes to restore a service after a failure, measured from the moment an incident begins to the moment normal service returns. It is one of the most common ways teams put a number on how well they recover from outages, and it is a good proxy for how much a typical failure actually costs you in lost availability.

The value of MTTR is not the exact figure. It is the trend. A team that watches MTTR over time can see whether its detection, alerting and response are getting better or quietly getting worse, and can point at the specific stages where time is being lost.

The four things MTTR can mean

The acronym is slippery. Four different metrics all get shortened to MTTR, and they measure different slices of an incident. Before you compare numbers with anyone, agree on which one you mean.

• Mean time to recovery (or restore): the average time from when an incident starts to when the service is working normally again. This is the most common reading and the one this guide uses.
• Mean time to repair: the average time spent actively fixing the problem, from when work begins to when the fix is in place. It excludes the time before anyone started.
• Mean time to respond: the average time from when an alert fires to when someone acknowledges it and starts working. This isolates how good your on-call and paging are.
• Mean time to resolve: the broadest reading. It includes recovery plus the follow-up work to stop the issue recurring, so it can stretch well past the moment users are unblocked.

These are not competing definitions to argue over. They are a way to break one number into stages, so you can see where the time actually goes.

How to calculate MTTR

The formula is simple: total downtime divided by the number of incidents in a period.

Say you had three outages last quarter that lasted 30, 60 and 90 minutes. Total downtime is 180 minutes across 3 incidents, so MTTR is 60 minutes. That single number now stands in for a typical recovery.

Two rules keep the figure honest. First, keep the time window fixed, for example a rolling 90 days, so you are always comparing like with like. Second, keep the definition of downtime consistent: decide up front whether the clock starts at the failure itself or at detection, and whether partial degradation counts. If the definition drifts, the trend becomes meaningless.

A mean also hides its own tails. One eight-hour outage can swamp a dozen quick recoveries and make the average look far worse than a normal incident feels. It is worth looking at the median alongside the mean, and at the worst case, not just the average.

When the clock starts and stops

Most of the time lost in an incident is often not the fix. It is everything before the fix.

Picture a typical timeline. The service fails at 02:00. Nobody notices until a customer emails at 02:40. An engineer acknowledges the page at 02:55, diagnoses the cause by 03:10, and ships the fix by 03:20. The repair took ten minutes. The recovery took eighty.

That gap between failure and detection is pure, avoidable downtime, and it is where automated monitoring earns its place. If a check had caught the failure at 02:01 and paged someone immediately, the same incident would have been a fraction as long, with no change to the fix itself. You can read how those checks work in what is uptime monitoring, and how to set them up in how to set up uptime monitoring.

MTTR, MTBF, MTTD and MTTA

MTTR sits in a small family of reliability metrics, and they are easy to mix up.

• MTBF, mean time between failures, measures how often something breaks. MTTR measures how long it takes to recover once it does. Reliability work pushes MTBF up and MTTR down together.
• MTTD, mean time to detect, measures the gap between a failure happening and anyone knowing about it. This is the stage monitoring attacks directly.
• MTTA, mean time to acknowledge, measures the gap between an alert firing and a human picking it up. This is a test of your alerting routes and on-call rotation.

Read together, they tell a story: how often you break, how fast you find out, how fast you respond, and how fast you recover.

How to reduce MTTR

Lowering MTTR is mostly about removing delay from the early stages, not about fixing faster under pressure.

• Detect sooner. The single biggest lever is catching failures automatically instead of waiting for a customer to tell you. Monitor from more than one location so a real outage is confirmed rather than guessed, which avoids both missed failures and noisy false alarms. Our guide on why a single monitoring location gives false alerts covers why that matters. You can also spot-check a URL right now with the free is it down checker.
• Route alerts to where people are. An alert that lands in an inbox nobody watches adds dead time. Send it to the channel your team already lives in. See uptime alerts in Slack and Discord and the full picture of downtime alerts.
• Classify quickly. A clear set of incident severity levels means responders know instantly how hard to push and who to pull in, instead of debating scope while the clock runs.
• Write runbooks. For the failures you have seen before, a short, tested set of recovery steps turns diagnosis from an investigation into a checklist. Runbooks are one part of a broader incident response plan.
• Practise. The first time you run a recovery should not be during a real outage. Rehearsed responses are faster responses.

Most of these lower the time before the fix, which is exactly where most incidents lose their minutes.

Why it matters

MTTR connects directly to the promises you make about availability. Every minute of recovery counts against your uptime, and if you have committed to a target, those minutes are your budget. That link is spelled out in what is an SLA. Watch MTTR, attack the stages that waste time, and the number comes down on its own.

Start monitoring free, no credit card, so a failure pages you in seconds instead of showing up in a customer email an hour later.