MTTR: The Formula, a Worked Example, and What Good Looks Like

Now look at the median. Sorted, the five values are 20, 45, 75, 130 and 390 minutes — the median is 75 minutes. The mean is nearly twice that, entirely because of one 6.5-hour incident. Report only the mean and you will look slower than you usually are; report only the median and you will hide the outage that actually cost the business something. Track both.

The Four Metrics That All Get Called MTTR

This is the single biggest source of confusion, and it is why two teams can both report "MTTR of 2 hours" while measuring completely different things.

One incident, four different answers

Detected Acknowledged Repair starts Service restored Ticket closed

Time to acknowledge

Time to repair

Time to recovery

Time to resolve

What Counts as a Good MTTR?

There is no credible universal benchmark, and you should treat any single number quoted as one with suspicion. An MTTR of four hours is excellent for a failed storage array requiring a hardware swap and terrible for a password reset. What a benchmark cannot know is your incident mix.

Three comparisons that are actually informative:

• Against yourself, by category. Network incidents this quarter vs last quarter is a fair comparison. Network vs access requests is not.
• Against your own SLA targets. If your resolution target for High priority is four hours and your MTTR for High is 3 hr 40 min, you are meeting the promise but with almost no margin — one bad week will breach it.
• Mean against median. A widening gap means outliers are growing. That is usually more actionable than the headline figure moving a few minutes.

What Actually Reduces MTTR

Most MTTR improvement comes from removing dead time, not from engineers working faster. In rough order of how much time they typically recover:

• Cut the acknowledge gap. Time between detection and someone picking the incident up is pure dead time, and it is usually the easiest interval to shrink with routing and alerting.
• Route on creation, not on inspection. Every handoff between engineers restarts the context-building. Automatic assignment by category and location removes most of it.
• Attach context to the incident. If the engineer opens the ticket already knowing the device, location, and recent history, they are not spending the first twenty minutes reconstructing the problem.
• Separate "waiting on someone else" from "working". Time spent waiting on a vendor or an approval inflates MTTR without telling you anything about your team. Track it separately or you will chase the wrong fix.
• Fix the recurring incidents. The same failure appearing monthly is a problem-management gap. No amount of faster response makes it go away.

Notice that only the last of these is about the technical fix. If your MTTR is dominated by detection and routing delay, buying faster engineers will not move it. This is the same pattern behind most SLA breaches: the target is missed in the gaps between work, not during it.

Measuring MTTR in InfraCue

To be precise about what the product does today: InfraCue timestamps every ticket at creation, at first response and at resolution, and the ticket report exports those columns — Created, First Response, Resolved — to CSV alongside the SLA state. That gives you everything needed to calculate MTTR and mean time to acknowledge in a spreadsheet, split by priority, category or location.

What it does not do is display MTTR as a built-in metric. The dashboard and wallboard show live SLA state — breached and near-breach counts, and a breakdown of tickets by state — rather than an average resolution time. If you want MTTR trended automatically rather than calculated from an export, that is not in the product yet.

The related mechanic worth knowing is that InfraCue's SLA clock genuinely pauses on Waiting for User, Waiting for Approval and Waiting for Vendor, pushing both deadlines forward by exactly the time spent waiting. So the SLA state you export is already free of third-party delay, even though the raw created-to-resolved gap is not. How the SLA timers work.

Common Questions

What does MTTR stand for?

Depending on who is using it: mean time to repair, mean time to recovery, mean time to resolve, or occasionally mean time to respond. They measure different intervals of the same incident, so the expansion matters. Always ask which one a figure refers to.

What is the difference between MTTR and MTBF?

MTTR measures how long you take to fix things; MTBF — mean time between failures — measures how long things run before breaking. MTTR is about response capability, MTBF about reliability. Together they give you availability: uptime improves either by failing less often or by recovering faster.

Should MTTR include time waiting on the requester or a vendor?

For an internal team metric, no — you cannot be accountable for time you do not control, and including it makes the number reflect your suppliers rather than your team. For a business-facing "how long were we affected" figure, yes, because the user was still waiting. This is exactly why you should keep time-to-repair and time-to-recovery as separate numbers.

Is a lower MTTR always better?

Not unconditionally. MTTR can be driven down by closing tickets prematurely, by classifying incidents as requests, or by applying workarounds instead of fixes — all of which look like improvement and cause repeat incidents. Read MTTR alongside reopen rate and repeat-incident count, or you will optimise the measurement instead of the service.

How many incidents do I need before MTTR means anything?

There is no strict threshold, but with fewer than about twenty incidents in a period a single outlier dominates the mean. At low volumes, report the median alongside it and quote the range rather than presenting one number as though it were stable.