MTTR - Mean time to repair
What is MTTR: mean time to repair explained
Mean time to repair (MTTR) is the average time needed to restore a failed asset to working order, found by dividing total repair time by the number of repairs over the same period. It is the standard measure of maintainability: not how often equipment breaks, but how fast your team gets it running again.
For field service
Know what the job needs before the van rolls
Venta Capture, a product of VentaVid, lets the customer show you the fault first, so the engineer arrives with the right part or does not need to arrive at all.
The abbreviation is where the trouble starts. MTTR is spelled out as mean time to repair, mean time to recovery, mean time to respond and mean time to resolve. Four different spans of the same incident, one acronym.
What does MTTR actually mean?
Decide which definition you are using and write it into the reporting standard before anyone publishes a figure. The four readings in circulation:
- Mean time to repair. Hands-on time only. The clock starts when repair work begins and stops when the asset is back in service. Waiting for a part does not count.
- Mean time to recovery, also called restoration. The clock starts when the failure is detected and stops when the asset is back in service. Travel, parts lead time and administrative delay all count.
- Mean time to respond. Detection to the moment someone actually starts work. A dispatch and logistics measure, not a repair measure.
- Mean time to resolve. Detection through to the underlying cause being dealt with, including follow-up work after service was restored.
Contracts are where the difference bites. A supplier guaranteeing a 24 hour repair time on top of six days of logistical delay is offering you nothing over a supplier guaranteeing seven day recovery, an illustration set out in the reference entry on mean time to repair. Same week without a machine. Very different-looking SLA.
How is MTTR calculated?
The formula is MTTR = total corrective repair time divided by the number of repairs in the same window. Keep one unit throughout, usually hours. Keep planned maintenance out of the numerator, because a scheduled belt change is not a repair, and keep the definition of the start and stop points identical for every asset in the report.
MTTR explained: a worked example
A packaging line fails five times in March. The repairs take 2.0, 4.5, 1.5, 6.0 and 3.5 hours of hands-on work, so 17.5 hours across five events gives an MTTR of 3.5 hours. Measure the same five failures from alarm to restart instead and the total is 41 hours, a mean time to recovery of 8.2 hours. Both numbers are arithmetically correct. Only the second one tells you the line was down for most of a shift each time.
How MTTR and MTBF combine into availability
On its own, MTTR says nothing about how often you are in trouble. Pair it with mean time between failures and you get inherent availability: Availability = MTBF divided by (MTBF + MTTR), read as a share of total time.
Run the packaging line through it. At 800 operating hours between failures and a 3.5 hour MTTR, availability is 800 divided by 803.5, or 99.6 percent. Cut MTTR to 2 hours and it rises to 99.75 percent. Leave MTTR alone and stretch MTBF to 1,200 hours instead and it reaches 99.71 percent. On this asset, repair time is the cheaper lever, and that comparison is exactly what the formula is for.
Where MTTR reporting goes wrong
Almost every argument about an MTTR figure turns out to be an argument about definitions rather than performance.
- Mixing the four definitions. One site reports wrench time, another reports alarm to restart, and the group dashboard averages them into a number that describes nothing.
- Starting the clock at the work order. If a fault sat unreported for six hours, those hours are real downtime. They belong in recovery, even though they are invisible in repair time.
- Averaging across asset classes. A conveyor motor and a control cabinet do not belong in the same mean. Split by criticality and asset family or the figure is decoration.
- Letting the mean hide the tail. Report the median and the 90th percentile alongside it. One 40 hour outage buried in a 3 hour average is the event that actually cost you the week.
What actually shortens MTTR
Most of the clock is usually spent before anyone touches the machine. Knowing what failed, which part is needed and which skill to send is where the hours go, which is why better remote triage and a serious pre-visit assessment tend to move MTTR further than shaving minutes off the repair itself.
The same information problem shows up in the neighbouring metric. When a technician arrives without the right part or the right diagnosis, it hurts first-time fix rate and MTTR at once, and a second visit turns a three hour repair into a two week recovery. Track both, define both precisely, and the pair will tell you where the delay really lives.
