Ask a maintenance manager for their MTTR and you'll get a number with confidence behind it — ask them to walk through exactly how it was calculated, and the confidence often wavers. Does the clock start when the machine stops, or when a technician is dispatched? Does it stop when the repair is physically done, or when the line is back to full speed? Does a five-minute reset after a false alarm count as a repair event at all? Every one of these decisions changes the resulting number, sometimes by a wide margin, and comparing MTTR figures calculated under different rules is comparing two different metrics wearing the same name. This guide lays out a defensible, consistent methodology for calculating MTTR — and if you'd like it applied automatically to your own maintenance data, book a demo with iFactory.
An MTTR Number You Can Actually Trust
Consistent event definitions and clock boundaries are what turn MTTR from a disputed number into a metric your whole team believes.
The Formula Is Simple. The Inputs Are Not.
MTTR's formula fits on one line: total repair time divided by number of repair events. The entire difficulty of calculating it consistently lives in defining what counts as "repair time" and what counts as a "repair event" — get those two definitions wrong and the formula produces a number that misleads more than it informs.
Number of Repair Events
Where the Clock Starts and Stops
The single most consequential decision in an MTTR methodology is defining the clock boundaries. Two plants measuring the exact same repair can produce meaningfully different MTTR figures purely from where they draw these lines.
Failure detected
Recommended start point: the moment the equipment stops or the fault is logged, not when a technician is later dispatched.
Technician arrives
Response time — the gap before this point — should be tracked separately from repair time, since it reflects staffing, not repair difficulty.
Repair completed
The physical fix is done, but the equipment may not yet be verified as ready to run at full rate.
Line back to full rate
Recommended stop point: verified return to normal production, not just the technician signing off the work order.
Get an MTTR Calculated the Same Way, Every Time
iFactory applies a fixed set of event and clock definitions automatically, so your MTTR trend is comparable month over month.
What Counts as a Repair Event — and What Doesn't
Not every stop is a repair event in the MTTR sense. A consistent methodology needs an explicit rule for the borderline cases, applied the same way across every asset and every shift.
Three Ways MTTR Gets Quietly Miscalculated
Beyond the core clock and event definitions, a handful of specific errors tend to creep into MTTR calculations over time as different people log data differently.
Including response time in repair time
Blending the wait for a technician to arrive into repair time conflates a staffing problem with a repair-difficulty problem, hiding which one actually needs fixing.
Averaging across incompatible asset types
A blended MTTR across a simple conveyor and a complex CNC spindle obscures which asset class actually drives the number, misdirecting improvement effort.
Manually logged end times rounded generously
A technician rounding a 47-minute repair down to 45 for the log seems trivial per event, but compounds into a meaningfully understated trend over a quarter.
Frequently Asked Questions
Should MTTR include the time waiting for a spare part to arrive?
This is one of the more debated methodology decisions, and the honest answer is that it depends on what question you're trying to answer. Many plants track two separate figures — active repair time, which excludes parts-waiting delay, and total downtime, which includes it — since blending the two hides whether a slow MTTR trend is a technician skill issue or a spares inventory issue. Whichever convention you choose, the important part is applying it consistently across every event.
How does MTTR calculation differ for automated versus manually logged data?
Automated calculation, pulled from PLC state changes and work-order system timestamps, removes the rounding and recall bias that creeps into manually logged repair times, since the clock starts and stops based on actual equipment state rather than a technician's memory of when they finished. This is one of the clearest cases where automated downtime capture produces a more defensible number than a paper work order.
What's a reasonable MTTR benchmark for manufacturing equipment?
Benchmark figures vary enormously by equipment complexity and industry, which is exactly why MTTR is more useful as a trend metric within your own plant than as a number compared against a generic external benchmark. A meaningful comparison requires knowing the other plant used the same event and clock definitions you did — absent that confirmation, treat any published "world-class MTTR" figure as a rough directional reference rather than a precise target.
Should every asset in the plant use the same MTTR calculation rules?
Yes — the clock boundaries and event definitions should be standardized plant-wide, even though the resulting MTTR values will naturally differ by asset complexity. Standardizing the methodology while expecting different absolute numbers per asset type is what makes cross-asset comparison meaningful; changing the definitions asset by asset defeats the purpose of the metric entirely.
How do we fix an MTTR calculation that's been inconsistent for years?
Document a single clear methodology going forward, communicate it to every technician logging repairs, and treat the changeover point as a break in the trend line rather than trying to retroactively normalize historical data to the new rules. Book a session with iFactory to set up automated, consistent MTTR tracking from that point forward.
Get MTTR That Means the Same Thing Every Month
Book a 30-minute demo and see how iFactory calculates MTTR consistently across every asset, shift, and repair event.
