MTTR is one of the most useful metrics a maintenance team can track — and one of the most frequently misunderstood. Here’s what it means, how to calculate it correctly, and how to use it to find real problems.
What MTTR Stands For (and Why There Are Three Definitions)
MTTR is an acronym that gets used in three slightly different ways depending on the context:
- Mean Time To Repair — the average time to physically repair a failed asset, from when the technician starts work to when the asset is functional again. This is the original engineering definition and the most common in maintenance operations.
- Mean Time To Restore — broader than repair: it includes everything from when the failure is detected to when the system is back in service, including response time, logistics, and testing. This is the definition most relevant to operations and production managers.
- Mean Time To Resolve — used in IT and service desk contexts; it includes the full elapsed time from incident report to ticket closure, often including verification and follow-up.
For maintenance teams managing physical assets, Mean Time To Repair is the standard definition. It measures how fast your team actually fixes things — diagnostic speed, technical skill, parts availability, and tooling. Unless this article specifies otherwise, MTTR here means Mean Time To Repair.
The MTTR Formula
The formula is straightforward:
MTTR = Total Repair Time / Number of Repairs
Both values need to come from the same time period and the same scope (same asset, same team, same facility — whatever you’re measuring).
Worked Example
Suppose you’re looking at Conveyor Belt #4 over the past 90 days. Your records show:
| Failure Event | Repair Time |
|---|---|
| Belt slippage — June 3 | 2.5 hours |
| Motor bearing failure — June 19 | 6.0 hours |
| Sensor fault — July 8 | 1.0 hour |
| Belt tension failure — July 22 | 3.5 hours |
Total repair time: 2.5 + 6.0 + 1.0 + 3.5 = 13 hours Number of repairs: 4
MTTR = 13 / 4 = 3.25 hours
On average, it takes your team 3 hours and 15 minutes to repair Conveyor Belt #4 when it fails. Whether that’s acceptable depends on the criticality of that asset and the cost of downtime while it’s offline.
What Counts as Repair Time
The boundary of what goes into “repair time” matters. For Mean Time To Repair, the clock typically runs from:
- Start: When a technician arrives at the asset and begins diagnosing or working on it
- End: When the asset is restored to operational status and confirmed functional
This means repair time includes:
- Diagnosis — identifying the root cause of the failure
- Parts retrieval — getting the needed parts from inventory (if this is within the shop)
- The physical repair — replacing, adjusting, rebuilding
- Testing and verification — confirming the fix worked before closing the work order
What it typically does NOT include (in the strict Mean Time To Repair definition):
- Time waiting for a technician to be dispatched
- Administrative delays (waiting for approval to start work)
- Waiting for a part to arrive from an external supplier
If you want to capture those delays, you’re measuring Mean Time To Restore, which is a more complete picture of total downtime impact.
For operational reporting, it’s worth tracking both: MTTR (repair efficiency) and actual downtime duration (operational impact).
What a “Good” MTTR Looks Like
There’s no universal benchmark that applies across industries and asset types. MTTR for a simple pump seal replacement is inherently different from MTTR for a CNC spindle rebuild. Comparisons only mean something within the same context:
- Same asset type over time — is your MTTR on Chiller Unit #2 improving, staying flat, or getting worse?
- Same team across facilities — is Site A’s team faster than Site B’s on similar equipment?
- Against your own previous periods — is your overall MTTR trending down as your PM program matures?
A low MTTR is generally good. But MTTR in isolation can be misleading — a team that consistently achieves low MTTR on simple failures while deferring complex ones will show a good number that doesn’t reflect reality. Pair it with failure frequency (MTBF) and total downtime to get a complete picture.
Using MTTR to Spot Problems
MTTR is most useful not as a single number but as a diagnostic tool when you slice it by different dimensions:
By asset: If one asset consistently has a much higher MTTR than similar assets, it may be worn beyond repair economics, or technicians may lack the specific knowledge to diagnose it quickly. Both are actionable findings.
By technician or team: A significant MTTR gap between technicians on similar work can indicate a training gap. It can also indicate that one technician is being assigned more complex jobs — context matters.
By failure type: If bearing failures take twice as long to repair as they should, it might be a tooling issue (the right puller isn’t in stock), a parts issue (bearings aren’t in local inventory), or a procedure issue (there’s no standard repair procedure written down).
By location: If repairs at a remote site take significantly longer than at your main facility, it might be parts logistics, technician coverage, or inadequate tools on site.
The pattern is the diagnostic, not the number itself.
MTTR and MTBF Together
MTTR and MTBF (Mean Time Between Failures) work as a pair:
- MTBF tells you how often an asset fails — reliability.
- MTTR tells you how quickly you recover when it does — maintainability.
Availability is a function of both:
Availability = MTBF / (MTBF + MTTR)
An asset with a high MTBF and a low MTTR is highly available. An asset that fails frequently (low MTBF) but is repaired quickly (low MTTR) may still achieve acceptable availability. An asset that fails infrequently but takes days to repair can still be a serious operational problem.
For a deeper look at MTBF and how it relates to failure frequency, see How to Calculate MTBF.
Why CMMS Makes MTTR Calculable
To calculate MTTR accurately, you need:
- A timestamp for when each repair started
- A timestamp for when each repair was completed
- A reliable link between the repair and the specific asset
Paper work orders and informal records almost never capture all three consistently. Technicians write down completion times but not start times. Work orders reference “Pump Room” instead of a specific asset. Timestamps get rounded or forgotten.
A CMMS solves this by making the labor log a structured part of every work order. Technicians log time against a specific asset, and the system records it. At the end of the period, MTTR is a straightforward calculation — not a reconstruction project.
For more on the metric itself, see the MTTR glossary entry.