MTTR (mean time to repair) is the average time taken to fix a failed asset and return it to service, from fault report to restored operation.
MTTR (mean time to repair) is the average time it takes to fix a failed asset and put it back to work, measured from the moment the fault is reported to the moment the asset is back in service. Where reliability metrics ask how often things break, MTTR asks how long they stay broken - it is the standard measure of maintainability, and the half of downtime that maintenance teams control most directly.
The MTTR formula
MTTR = total repair time ÷ number of repairs.
A worked example: a machine breaks down four times in a quarter, and the repairs take 2, 6, 3 and 5 hours from report to return to service. MTTR = (2 + 6 + 3 + 5) ÷ 4 = 4 hours.
The inputs come straight from repair records: each service ticket needs a reported-at time and a resolved-at time. If faults are reported by shouting across the workshop, there is nothing to calculate.
What the repair clock includes
MTTR is not just wrench time. The clock typically covers:
- Detection and reporting - the gap between something breaking and someone logging it.
- Diagnosis - working out what is actually wrong.
- Waiting - for parts, for a technician, for an external repairer. Usually the largest share by far.
- The repair itself - often the shortest stage.
- Testing and return to service - confirming the fix before the asset goes back to work.
Organisations draw the start and stop lines differently - some clock from failure rather than report, some stop at fix rather than return. The convention matters less than consistency: MTTR is most useful as a trend, and a trend only means something if the measurement stays the same.
MTTR vs MTBF
MTBF (mean time between failures) measures how often an asset breaks; MTTR measures how long each fix takes. They are independent and they fail differently: a high-MTBF, high-MTTR asset rarely breaks but vanishes for a week when it does, while a low-MTBF, low-MTTR asset nags constantly but never stops the job for long. Availability combines them - MTBF ÷ (MTBF + MTTR) - so when uptime disappoints, the pair tells you whether to invest in reliability or in faster repairs.
How small teams reduce MTTR
Most MTTR is waiting and hunting, not repairing, which is why the practical fixes are unglamorous:
- Make reporting instant. A fault logged at the machine, with photos, the moment it is noticed removes the silent day or two before anyone official knows. With AMPthilly, scanning the QR label on a faulty item opens its record in the phone browser, where anyone can report the issue with photos and a category on the spot.
- Keep the paperwork on the asset. Manuals, purchase receipts, and supplier details attached to the record kill the where-did-we-buy-this hunt - and checking warranty status first can turn a paid repair into a free one.
- Make the waiting visible. Ticket statuses such as “awaiting parts” show where repair time actually goes, which is the only way to fix the right bottleneck.
- Stock the usual suspects. For a fleet of golf carts or ATVs, a shelf of batteries, belts, and tyres converts week-long waits into same-day fixes.
Chronically high MTTR on one asset is also a signal in its own right: when every fix takes longer because parts are scarce and faults compound, the machine is telling you it is near the end of its useful life, and the next work order conversation should include the word “replace”.
Related terms
- Work Order - the job record whose open-to-close time feeds MTTR
- Service Ticket - the fault report that starts the repair clock
- Warranty Tracking - the check that can make a repair the supplier’s problem
- End of Life (EOL) - where chronically slow, frequent repairs should lead
- Useful Life - the planned service span rising MTTR erodes