MTTR is mean time to repair: the average time it takes to get a failed asset back into service, from the moment it stops to the moment it runs again. Where MTBF measures how often things fail, MTTR measures how long each failure costs, and the two together are most of what a maintenance manager needs to know about an asset. This page gives the mttr formula, what is mttr in maintenance as opposed to in IT, the mttr calculation from real work order times, and how to calculate mttr for one asset or for the whole team.
The formula and the clock
MTTR equals total repair time divided by the number of repairs. The argument is always about when the clock starts and stops. The honest version runs from the failure being reported to the asset being handed back, because that is the time the operation lost; a version that counts only wrench time flatters the team and hides the waiting. Whichever you choose, use it consistently, because the value of MTTR is in the trend and a change in the definition looks like a change in performance.
A calculation from one asset's work orders
A filling machine had five reactive work orders in a quarter. The reported-to-returned times were 2.5, 4, 1.5, 6 and 3 hours, which is 17 hours in total. MTTR is 17 divided by 5, which is 3.4 hours, the same figure the worked example on this site uses for a breakdown. The six-hour job is worth opening: if four of those hours were waiting for a part, the fix is a spare on the shelf, not a faster technician.
MTTR for a whole site
Add every reactive work order's repair time across all assets and divide by the count, and you have the site's MTTR. It is a blunt figure because it mixes a five-minute reset with a two-day rebuild, so most teams read it alongside the distribution: how many repairs took under an hour, how many took over a shift. A site MTTR that is rising while the asset MTTRs are steady usually means the mix has shifted towards bigger failures, which is a schedule problem rather than a repair problem.
What moves it
Diagnosis time, which drops when the work order history says what was found last time. Waiting for parts, which drops with the right spares held. Waiting for access or lockout, which is procedural. And the repair itself, which is the only part training changes. Reading MTTR without splitting it into those four is how teams buy training when they needed a spare.
Questions people ask about mttr formula
What is a good MTTR?
One that is falling for the assets you are working on. There is no benchmark that survives the differences between a conveyor and a compressor, so compare an asset with its own history.
Does MTTR include the time waiting for a part?
It should, if you want the figure to describe what the operation lost. Keep a note of the split so that waiting time is visible as its own problem.
Is MTTR the same in maintenance and in IT?
The formula is the same. In IT the asset is a service and the repair is a restore; in maintenance it is a machine and a physical fix. The reason to know the difference is that most articles about MTTR are written for IT and assume a restart is a repair.
How many repairs do I need before MTTR means anything?
Enough that one long job does not move the average by half. For a single asset that is usually a quarter's worth; for a site, a month.