MTTR: What It Means, How to Calculate It, and How to Actually Reduce It

MTTR usually stands for mean time to resolution: the average time from incident start until service is restored and the fix confirmed. The same four letters also cover mean time to repair, recovery, and respond. Each measures a different slice of the incident. The first step to reduce MTTR is agreeing which one you’re tracking.

The confusion runs along industry lines. Maintenance software uses it for machine repair. Security platforms clock response and containment. Software teams track recovery and resolution, and most guides blur all four.

At IWConnect we’ve run incident response for enterprise clients since 2004, first as a managed services practice. Argus, our incident response agent, grew out of that work. This guide defines every variant, then commits to the one software teams actually report.

What does MTTR mean?

MTTR is a family of four metrics, and the final R decides what you’re measuring. Mean time to repair and mean time to recovery track how long fixes take. Mean time to respond tracks how fast a team engages. Mean time to resolution spans the whole incident, from start to confirmed fix.

Ask a plant maintenance manager about MTTR and you’ll hear about conveyor motors and spare parts. That world has meant mean time to repair for decades. Ask a security lead and it means speed of response and containment. Ask a software team and it means getting the service back and the ticket closed.

Same acronym, three industries, four clocks.

Inside software, the two that get conflated are recovery and resolution. Recovery stops the clock when users can work again. Resolution keeps it running until the underlying cause is fixed and verified. A restart that buys you an hour counts as recovery, nothing more.

Plenty of tools report one while their docs describe the other, so check before you trust a dashboard.

For software operations, mean time to resolution is the most honest choice. It covers the stretch your customers actually feel, plus the check that the fix held. Mean time to recovery is the right lens for pure availability work.

How do you calculate MTTR?

MTTR equals total resolution time divided by the number of incidents in the same period. Add up how long each incident took from start to confirmed fix, then divide by the incident count. Ten incidents adding up to 15 hours of resolution time give an MTTR of 90 minutes.

Here’s the arithmetic on a real week. Monday brings a bad deploy, detected at 09:12 and rolled back and verified by 09:58, so 46 minutes. Wednesday brings a database failover that takes 3 hours 20 minutes to fully resolve, and Friday a certificate expiry fixed in 24. Three incidents, 270 minutes, an MTTR of 90 minutes, with one Wednesday carrying most of the number.

The formula is the easy part. Two decisions change the number more than any tooling will. First, when does the clock start: when the failure occurred, or when you detected it? A failure that sat silent for five hours looks very different under each rule.

Second, when does it stop: when service is restored, or when the fix is verified and the ticket closed? Pick one rule for each question, write both down, and never compare numbers calculated under different rules.

Then report the denominator next to the average. An MTTR of 90 minutes across 200 incidents is a stable signal. The same 90 minutes across 4 incidents is one rough night away from doubling.

Small incident counts make averages jumpy. That’s why we publish our own numbers with the sample attached.

What’s a good MTTR?

There is no universal good MTTR. The number depends on which definition you use and what you count as an incident.

Vendor benchmarks deserve extra suspicion, ours included. It’s the reason every figure in this post carries its denominator. A vendor averaging repair-based MTTR across manufacturing clients describes a different universe from your API outage.

Severity mix distorts comparisons too. A team that logs every blip as an incident shows a shorter average than a team that only counts real pages. Neither is faster.

One blended number also hides more than it shows. Track MTTR per severity tier instead: your P1 average and your P3 average describe different risks and deserve different targets. A single company-wide figure mostly tracks whichever tier had the busiest month. That makes it easy to celebrate an improvement that never happened.

The benchmark that changes behavior is your own trend. Cut resolution time from three hours to one over a quarter and you’ve done something real. Whatever anyone else’s chart says. Re-check the trend quarterly, on the same rules.

Why does MTTR matter, and what does the average hide?

MTTR matters because it prices reliability in time: every unresolved minute costs revenue, SLA credits, customer trust, and engineer hours. It’s also a mean, and means hide tails. A healthy-looking average can sit on top of one six-hour outage blended with twenty quick restarts.

The tail is usually where the business damage lives. So look past the average. Plot the distribution, track the 90th percentile, and review your three worst incidents each month by hand. The median tells you about the typical incident. The tail tells you what your worst week costs.

Watch the incentive problem too. Turn MTTR into a target and people will close tickets faster without fixing anything. They’ll relabel incidents to keep them out of the count. Or they’ll patch symptoms while the cause survives to page someone next week.

Pair it with recurrence tracking and change failure rate so speed can’t be bought with rework. The deepest fix for a bad tail is studying it properly.

How do you reduce MTTR?

You reduce MTTR by attacking the slowest stage of your incidents, and for most software teams that stage is diagnosis. Monitoring finds problems in seconds. Fixes are usually quick once the cause is known. The stretch in between, working out what actually broke, is where resolution time goes to die.

Break every incident into four stages and time each one: detect, diagnose, fix, verify. The ops teams we’ve measured lost 20 to 45 minutes per incident on diagnosis alone. That’s the gap between the alert and a first credible hypothesis. Everything else took minutes, so work the stages in order of pain:

1. Detect faster with fewer, better alerts. Alert on symptoms customers feel and route pages straight to the service owner. Kill duplicates so responders trust what fires. A page that reaches the wrong person costs more time than a slow query ever will. Alert quality is also a cost lever. One of our teams wrote up how they cut IT monitoring costs by $100K while keeping coverage intact.
2. Diagnose faster by putting context in one place. Correlate every incident with recent deploys, because most production incidents follow a change. Keep service topology current so blast radius is obvious at a glance. Automating that correlation, automated root cause analysis, is a discipline of its own.
3. Fix faster by rehearsing the fix. Feature flags, one-command rollbacks, and rehearsed steps turn a known cause into a short outage. Runbooks earn their keep here: a fix an engineer has walked through at noon takes half the time at 3am.
4. Verify and learn. Confirm the fix held. Then feed what you learned back into runbooks and alert rules so the next one dies sooner.

None of it sticks without a defined incident management process for how incidents get declared, owned, and escalated. If your shop runs on ITIL, its incident practice maps onto these same stages. Google’s SRE book makes the underlying point well. A team with a clear incident command structure resolves faster than a smarter team without one.

In our own managed services practice, the biggest single MTTR win has rarely been a new tool. It’s been putting deploy history, monitoring, and ownership in front of the responder at the same moment.

Where does AI fit in reducing MTTR?

AI cuts MTTR by compressing diagnosis: an agent reads every tool at once and hands the engineer ranked root-cause hypotheses with evidence attached. The engineer still makes the call. What changes is how long it takes to have something worth deciding on, at 2pm or at 2am.

The mechanics are simple to describe and hard to do well.

When an alert fires, the agent queries monitoring, logs, traces, deploy history, and topology in parallel. It correlates what comes back and writes a briefing. Likely causes come ranked by confidence, each backed by a numbered evidence chain. The on-call engineer opens one screen instead of six tabs.

We built Argus because we’d spent years doing that correlation by hand. In one 30-day production window, Argus ran 40 automated investigations. 33 of the 40 returned an actionable root-cause hypothesis at 70% confidence or higher, an 83% actionable rate. The average run took 41 seconds from alert to root cause, against a 30-minute manual baseline.

It flagged 25 of those 40 incidents as recurring patterns it recognized from history. Total AI processing time for the window came to 27 minutes. That stood in for about 20 hours of manual work. Cost per investigation: about $0.0105.

Measured across deployments, the overall cut in diagnosis time lands between 40 and 70%.

The compression shows up around the edges of the incident too. Escalation calls used to ride on gut feel. Now they get made with service topology and blast radius on screen, inside 90 seconds. Shift handovers that ran on 20 to 30 minutes of verbal catch-up become a 5-minute review of the investigation log.

Neither shows up in the MTTR column directly, and both decide how the next incident starts.

The caveats are real. An agent’s hypothesis is only as good as the telemetry it can read, so thin monitoring produces thin briefings. A confidence score is a ranking aid. An engineer still confirms the cause before anything gets rolled back.

And diagnosis is the stage AI compresses best. If your slowest stage is a change approval board, fix that first. We go deeper in our guides to incident response automation and predicting system failures before they happen.

Want to see the diagnosis stage compressed on your own stack? Bring us one of your incidents and we’ll run it through Argus live, mapped to your monitoring and deploy tools. Get in touch and we’ll set it up. No slides, just your incident and a stopwatch.

Frequently asked questions about MTTR

What’s the difference between MTTR and MTBF?

MTBF, mean time between failures, measures reliability: how long a system runs before something breaks. MTTR measures how fast you recover once it does. Read together, they tell you whether you’re fighting frequent small fires or rare long ones. Each problem calls for different work.

Is a lower MTTR always better?

Lower is better only when the fixes are real. An average pushed down by fast ticket-closing, relabeled incidents, or symptom patching will come back as repeat incidents. Track recurrence and change failure rate alongside MTTR so a falling number means truly faster recovery.

Does MTTR include detection time?

That depends on where you start the clock. Starting at failure occurrence includes detection lag. Starting at the alert excludes it. Many teams track detection separately as MTTD, start MTTR at detection, and document the rule for every incident.

What’s the difference between MTTR and MTTA?

MTTA, mean time to acknowledge, measures the gap between an alert firing and a human accepting it. It’s the first slice of response time. A long MTTA usually points at paging problems, unclear ownership, or alert fatigue rather than technical difficulty.