MTTR – Mean Time To Repair: Definition, Formula and How to Reduce It

MTTR measures the average time a maintenance team needs to restore a failed machine, system, or component to full operation after a breakdown is detected. It covers the full repair cycle: fault detection, diagnosis, actual repair, and functional testing before restart. As a core KPI in maintenance management, MTTR directly reflects how responsive and efficient a team is when equipment fails. A lower MTTR means less unplanned downtime, fewer production losses, and lower repair costs per incident.

Closely related metrics include MTBF (Mean Time Between Failures) and MTTF (Mean Time To Failure). All three form the basis for calculating overall equipment availability and OEE.

How is MTTR calculated?

MTTR uses a straightforward formula:

MTTR = Total Repair Time / Number of Repairs

Example: A production line experienced five failures in one month. The combined repair time across all five incidents was 10 hours. MTTR = 10 / 5 = 2 hours per failure.

The clock starts when the failure is detected and stops when the system is confirmed fully operational again. This means diagnosis time, waiting for spare parts, the hands-on repair itself, and post-repair testing all count. Administrative delays such as shift handovers or permit-to-work processes are also included if they extend the downtime window.

What is the difference between MTTR and MTBF?

MTTR and MTBF measure two distinct aspects of maintenance performance and answer different questions.

MTTR measures responsiveness: how fast failures are resolved once they occur.

MTBF measures reliability: how long equipment runs between failures.

The target in any maintenance program is a high MTBF combined with a low MTTR. Failures are infrequent, and when they do occur, they are resolved quickly. Used together, both KPIs determine asset availability: Availability = MTBF / (MTBF + MTTR). A team that improves only MTBF without addressing MTTR will still lose significant uptime whenever failures do happen.

What is the difference between MTTR and MTTF?

MTTF (Mean Time To Failure) applies exclusively to non-repairable components such as light bulbs, bearings, or single-use sensors. It measures how long a component operates before it fails permanently and must be replaced. MTTR, by contrast, applies to repairable systems and measures how long restoration takes after a failure event. Confusing the two leads to incorrect asset lifecycle decisions. A component with a short MTTF needs a replacement strategy, not a faster repair process.

What are the most common MTTR measurement errors?

Many teams track MTTR incorrectly and do not realize it until their numbers stop reflecting reality. The most frequent error is reporting Mean Down Time (MDT) while calling it MTTR. MDT includes all downtime from failure to restart, including parts shipping delays and administrative holds. MTTR, strictly defined, covers only active repair time. Mixing the two inflates your figures and makes cross-team benchmarking meaningless.

Other common errors include:

Inconsistent clock start points: one technician starts timing on arrival at the machine, another on closing the work order. Both produce different numbers for the same repair.
Including planned maintenance events: scheduled PM tasks are not failures. Counting them pulls the average down artificially.
Rounding repair times: teams using paper logs often round to the nearest hour, destroying the precision needed for trend analysis.

When does MTTR make sense as a KPI, and when does it not?

MTTR delivers clear value wherever unplanned downtime generates direct production losses: manufacturing plants, food processing lines, energy infrastructure, and logistics operations. Tracking it per asset, per failure type, and per maintenance team reveals where response bottlenecks actually sit.

MTTR becomes misleading when used as the only maintenance KPI. A team can artificially lower MTTR by closing work orders before full functional testing is complete, which shifts the problem rather than solving it. MTTR also loses meaning when failure frequency is very low: a single major breakdown with a 20-hour repair time in a quarter produces the same MTTR as five minor four-hour repairs, but the underlying problems are entirely different. Always read MTTR alongside MTBF and failure rate data.

How can MTTR be reduced in practice?

Reducing MTTR requires targeting the specific phase of repair that consumes the most time. Diagnosis typically accounts for the largest share of total repair time, especially when fault history is unavailable or undocumented.

Practical measures by repair phase:

Detection: Real-time alerts from connected machines shorten the gap between failure occurrence and notification to the maintenance team.
Diagnosis: Digital fault logs with repair history for each asset allow technicians to identify recurring failure patterns within minutes instead of hours.
Parts access: A managed spare parts inventory with defined minimum stock levels eliminates wait time for common components.
Repair execution: Standardized work instructions for frequent failure scenarios remove the need for improvisation under time pressure.
Testing: Defined acceptance criteria for post-repair testing prevent repeat breakdowns caused by premature restart.

Mini-Case: Bottling Line, Food & Beverage

A bottling plant tracked an average MTTR of 4.2 hours per filling machine failure. Root cause analysis showed that 60% of that time was spent on diagnosis because fault history existed only in paper logbooks. The team standardized digital fault recording on each machine, linked to the work order system. Within 60 days, diagnosis time dropped by roughly half. MTTR fell to around 2.5 hours per incident, recovering approximately 90 production hours per quarter on a single line.

Structured capture of repair data is exactly what makes results like this repeatable and scalable across sites. flowdit digitizes work orders and maintenance logs directly on mobile devices, so MTTR reports are generated automatically from real timestamps — without spreadsheets or manual data entry.