Mean time to repair
How long, on average, it takes to get a failed asset running again.
01 What it is
Why anyone looks at this number
How long, on average, it takes to get a failed asset running again.
MTBF tells you how often things break. MTTR tells you what each break costs in lost hours. Maintenance programmes are usually designed around the first and judged on the second.
02 The formula
How it is worked out
Mean time to repair = total_downtime_hours ÷ number_of_failures grain : month × asset class × site unit : hours per failure source : CMMS work orders, joined to the asset register and production downtime records
Split waiting time from wrench time. Most of MTTR is usually waiting — for a technician, a permit or a spare part — and each of those has a completely different fix from the repair itself. A single elapsed number sends the improvement effort to the wrong place.
03 Worked example
The same number, with real inputs
| Total downtime | 214 hours |
| Failures | 47 |
| Of which waiting for parts | 146 hours |
| Calculation | 214 ÷ 47 |
| Result | 4.6 hours |
3.1 of the 4.6 hours is waiting for spares. The maintenance team is not slow; the stocking policy is the constraint, and it is a cheaper thing to fix.
04 What moves it
Four things that actually change this number
Spares availability
Usually the largest single component, and a stocking decision.
Diagnosis time
Condition data and failure history shorten it more than skill does.
Technician coverage
Shift patterns decide whether a night failure waits until morning.
Asset access
Permits, isolation and safety steps, which are not negotiable but are plannable.
05 Where the number lives
The system, the record and the fields
| System of record | Key record | Fields you need |
|---|---|---|
| CMMS work orders, joined to the asset register and production downtime records | Asset joined to Work order and Failure event | asset_id, asset_class, failure_time, response_time, repair_start, repair_end, failure_code, part_id |
Split waiting time from wrench time. Most of MTTR is usually waiting — for a technician, a permit or a spare part — and each of those has a completely different fix from the repair itself. A single elapsed number sends the improvement effort to the wrong place.
06 How it goes wrong
Three ways this metric misleads people
The clock starting at repair
The hours between failure and someone arriving disappear from the metric.
Fix: Start at the failure event, and record response separately.Mixing asset classes
A conveyor and a packaging line average into a number that describes neither.
Fix: Report by asset class, and by criticality.MTTR without MTBF
Fast repairs on an asset that fails weekly still stops production weekly.
Fix: Report both, and the resulting availability.08 Questions
Frequently asked
Is MTTR a maintenance metric or a production one?
Both, which is why it is so often argued about. Production owns the lost hours, maintenance owns the repair, and the waiting time in between usually belongs to neither until someone measures it.
How does condition monitoring change it?
It moves failures from unplanned to planned, which shortens repair time and removes most of the waiting. The gain shows up in MTTR long before it shows up in MTBF.
One definition, everywhere it is used
SCIKIQ stores this metric once and serves it to every dashboard, board pack and agent that asks.