Ask five people on a plant floor what MTTR means and you'll often get five slightly different answers — some will say it's purely the wrench-time a technician spends on a repair, others will include the wait for a spare part, and a few will fold in the time spent diagnosing what actually broke in the first place. That inconsistency matters more than it sounds, because a maintenance team can't meaningfully improve a number nobody agrees on the definition of, and two plants comparing their MTTR figures may not actually be comparing the same thing at all. A demo can show how a consistent MTTR calculation gets tracked automatically across every asset.
What MTTR Actually Measures
Mean Time to Repair is the average total time an asset spends unavailable due to a failure, measured from the moment the failure is detected to the moment the asset is confirmed back in working order. It is not simply the hands-on repair time a technician logs on a work order — a complete MTTR figure includes detection time, diagnosis time, the wait for parts or tools if the technician doesn't have them on hand, the actual repair work, and any verification testing before the asset is released back to production. Leaving any of those stages out understates the real cost of downtime and makes the number look better than the plant's actual experience.
A Worked Example From a Real Production Line
Consider a conveyor motor that fails three times in a month. The first failure takes 40 minutes to notice, 20 minutes to diagnose as a bearing failure, 90 minutes waiting for the replacement bearing from the plant's own stores, 45 minutes to physically complete the repair, and 15 minutes to verify the conveyor runs correctly under load — a total of 210 minutes. The second failure, caught faster because an operator immediately recognized the same fault pattern, totals 140 minutes. The third, which required a part not in stock and a two-hour supplier run, totals 320 minutes. Adding these three events together gives 670 minutes across three repairs, for an MTTR of roughly 223 minutes, or just over three and a half hours per failure.
That example illustrates why MTTR is genuinely useful as a diagnostic number rather than just a scorecard metric — the three events above have wildly different root causes for their length. The first event's 90-minute parts wait points toward a spares inventory gap. The second event's faster detection shows what's achievable when an operator recognizes a known fault pattern quickly. The third event's supplier run points toward a stocking decision that needs revisiting. A single average MTTR number hides all three of these distinct stories unless the underlying event data is broken down by stage.
Breaking MTTR Into Its Component Stages
| Stage | What It Captures | Common Improvement Lever |
|---|---|---|
| Detection time | Time from actual failure to someone noticing it | Condition monitoring and automated alerting |
| Diagnosis time | Time to identify the specific root cause | Historical fault pattern matching and technician training |
| Parts wait time | Time waiting for the correct spare part or tool | Spares inventory optimization and stocking policy |
| Repair time | Actual hands-on time completing the fix | Standardized repair procedures and technician skill |
| Verification time | Time confirming the asset works correctly before release | Standardized test procedures and checklists |
MTTR and MTBF: Related but Different Questions
MTTR and MTBF are frequently mentioned in the same breath, and it's worth being precise about the difference, since confusing the two leads to confusing conclusions. MTTR answers "how long does it take to fix something once it fails," while MTBF answers "how often does it fail in the first place." A plant can have an excellent MTTR — fast, efficient repairs — while still suffering from poor overall availability if MTBF is low and the asset simply fails too often. Conversely, a plant with a high MTBF but a poor MTTR can still lose significant availability on the rare occasions something does break, because each event drags on far longer than it needs to. Improving overall equipment availability generally requires attention to both numbers, not just one.
Why Manual MTTR Tracking Usually Understates the Real Number
Most plants that track MTTR manually rely on the timestamps a technician enters on a work order, which typically only capture when the repair itself started and ended — the detection and diagnosis time before the work order was even opened is often invisible to the system entirely. That gap means a manually tracked MTTR figure is frequently measuring only the middle portion of the real downtime experience, which can make a plant's repair performance look considerably better on paper than production actually experienced it.
Automated tracking that ties directly into machine state data closes this gap by timestamping the actual moment an asset stopped, rather than relying on someone to manually log it. When that timestamp is compared against the moment a work order was opened, the gap between the two becomes visible as detection time, and it often turns out to be a meaningfully large and previously invisible component of total downtime once it's actually measured rather than assumed to be negligible.
