MTTR Meaning: How to Measure and Reduce Mean Time to Repair

MTTR Meaning: How to Measure and Reduce Mean Time to Repair

A pump fails at 06:40. Production notices the line has stopped at 07:10. The supervisor logs a job at 07:35. A technician gets to it at 08:20, spends forty minutes working out what's wrong, then discovers the seal kit isn't on the shelf. The line comes back at 13:15. That's six and a half hours of downtime — and maybe forty minutes of it was actual repair.

That gap, between how long a fix takes and how long the asset is actually down, is the whole story of MTTR. It's one of the reliability metrics in the maintenance KPIs guide, and it's the one that tells you the most about your team rather than your equipment. This is the detail: what MTTR means, how to calculate it, and where the time really goes.

What MTTR Actually Means

MTTR stands for mean time to repair — the average time it takes to restore a failed asset to working order. Where MTBF (mean time between failures) measures how reliable your equipment is, MTTR measures how fast you recover when it lets you down. You can't always stop a failure; you can nearly always recover from it faster.

Here's the first trap, and it catches almost everyone. The "R" in MTTR is ambiguous. Depending on who's talking, it means one of four different things:

• Mean time to repair — the wrench time. From when work starts to when the fix is done.
• Mean time to recover — the full outage. From the moment it fails to the moment it's producing again.
• Mean time to respond — from the alert to someone actually working on it.
• Mean time to resolve — the widest of all: detect, diagnose, repair, and make sure it doesn't happen again.

Four metrics, one acronym. This isn't pedantry — it's why two teams quote wildly different MTTR numbers for the same event. If your clock starts when the spanner touches the bolt, you'll report forty minutes; if it starts when the asset went down, six and a half hours. Before anyone tracks MTTR, agree which clock you're running. On a maintenance shop floor the number that matters to the business is nearly always the full recovery: failure to running. That's what production loses, and it's what we use throughout this guide.

The MTTR Formula

The calculation is simple. Add up all the downtime caused by failures over a period, then divide by the number of failures:

MTTR = Total downtime from failures ÷ Number of failures

Two things to get right. First, be consistent about what "downtime" includes — failure-to-running, as above, not just wrench time. Second, only count unplanned failures; planned maintenance and scheduled shutdowns don't belong in an MTTR figure and distort it depending on how much planned work you did.

A Worked Example

Take one asset over a quarter. It failed six times, and here's the total downtime each failure caused, from stop to restart:

MTTR = 19.0 ÷ 6 = 3.17 hours.

So on average, when this asset fails, it's down for a little over three hours. That's your baseline. On its own the number is inert — it only becomes useful when you track it over time (is it trending down?) and when you break it apart to see where those three hours actually go. If you just want the figure for your own assets, run them through the MTTR calculator.

The Four Things That Inflate MTTR

Go back to the pump. Six and a half hours of downtime, forty minutes of repair. The other five-plus hours went on noticing, dispatching, diagnosing, and waiting for a part. Every MTTR figure is really the sum of four stages, and to cut the number you have to know which stage is eating it.

Most teams assume MTTR is about the repair — better technicians, faster wrenches. Usually it isn't. In the pump example the actual repair was the smallest slice; the time lived in detection, response, and diagnosis. That's good news: those three are the cheapest to fix, because they're about information and process, not skill.

Reducing Detection Time

You can't repair what you don't know is broken. Thirty minutes passed before anyone realised the pump was down. Make failures visible the moment they happen — condition monitoring on critical assets, and a dead-simple way for operators to raise a fault the instant they see one. A QR code on the machine that logs a job in ten seconds beats a walk to the office. If reporting a fault is harder than ignoring it, operators will ignore it.

Reducing Response Time

Twenty-five minutes between the fault being logged and a technician being assigned. This is pure process. The fix is clear ownership and clear priority: every incoming job routed to someone and ranked, so the line-stopping failure jumps the queue instead of sitting behind a flickering light in the canteen. Good work order management is most of the battle — a job that lands on the right person's screen with the right priority is halfway to being started.

Reducing Diagnosis Time

Forty-five minutes working out what was actually wrong. Diagnosis is where asset history earns its keep. A technician who can pull up the last five things that went wrong with this exact pump — and what fixed them — diagnoses in minutes, not hours. One staring at an unfamiliar machine with no records starts from scratch every time. Keep a clean maintenance history against every asset and attach the manuals to the record, and diagnosis stops being detective work.

Reducing Repair Time

The seal kit wasn't on the shelf. This is the most expensive stage to get wrong and the most avoidable. The biggest lever is spares: the right part, on the shelf, for your critical assets — stock-outs on parts you know you'll eventually need turn a one-hour job into a next-day job. Behind that sit two smaller levers: a documented repair procedure so the fix doesn't hinge on one person's memory, and not waiting on an external specialist for routine work. Get the parts and procedures for your worst failures ready before the failure, not scrambled for after it.

Using MTTR Without Being Fooled by It

A few honest cautions, because MTTR is easy to misread.

• It's an average, so it hides its extremes. One eight-hour catastrophe and a run of quick fixes can average out to something that looks fine. Watch the spread, and look at your worst failures directly.
• Pair it with MTBF, never alone. MTTR tells you how fast you recover; MTBF tells you how often you're failing. A brilliant MTTR on an asset that fails weekly is still a bad asset.
• Track it per asset, not just plant-wide. A single site-wide MTTR is nearly useless for action. Per-asset, it points straight at your bad actors.
• Don't game the clock. If MTTR looks good because the clock starts late or jobs close early, someone eventually notices. Anchor it to real events: the actual stop and the actual restart.

The point of MTTR isn't the dashboard reading. It's the conversation where you look at three hours of average downtime, break it into the four stages, and realise two of those hours are detection and parts — both of which you can fix this month without hiring anyone.

Turning the Number Into Action

None of this works without clean data underneath. To split MTTR into detection, response, diagnosis, and repair, you need timestamps: when it failed, when it was reported, when work started, when it was fixed. Most teams capture none of that — they log "pump repaired, 3 hours" and lose the story of where those three hours went.

A CMMS earns its place by capturing those timestamps as a by-product of work already happening. When operators raise faults by scanning the asset, technicians start and stop jobs on their phones, and every repair is logged against the asset's history, MTTR — and its breakdown into stages — becomes a report, not a research project.

If you're trying to measure MTTR properly and cut it stage by stage, book a call and we'll show you how teams set this up in AssetOS — usually with per-asset MTTR live within a couple of weeks.