MTTR

What is MTTR?

MTTR (Mean Time to Repair, in standards also Mean Time to Restoration) is the average time required to get a system, machine or component fully working again after a failure, calculated as the total repair time divided by the number of failures in a period. MTTR is an important KPI in maintenance, IT/OT management and production, because repair time directly determines how much availability and output a failure costs. Where MTBF tells you how often something breaks down, MTTR tells you how quickly you can restore it.

🧠 How is MTTR calculated?

The basic formula is simple:

MTTR = total repair time / number of failures

For example: a packaging line had 4 failures in a month and the repairs took 8 hours in total. The MTTR is then 8 / 4 = 2 hours.

In practice the difficulty is not in the division but in the agreements around it:

• When does the clock start? At the moment of failure, at the first alarm, or when the work order is created?
• When does the clock stop? After the repair, after the functional test, or only when the installation is producing at nominal speed and quality again?
• Which failures count? Only unplanned downtime, or also short stops that the operator clears without help?
• Which unit? Hours, minutes or production cycles, per machine, line or whole plant.

An MTTR figure is only comparable between lines, sites or suppliers once those choices are fixed and applied the same way everywhere.

🔤 What does the R in MTTR stand for?

Different disciplines fill in the acronym differently. That regularly causes confusion, for example when a supplier states an MTTR in a datasheet and the operator measures something else.

The key distinction is whether detection time is included. For a failure that an operator sees immediately, it makes little difference. For a hidden failure in a safety function that is only discovered at the next proof test, the difference can be weeks.

🛠 Which phases make up repair time?

A failure roughly passes through six phases. If you want to reduce MTTR, you need to know in which phase the time disappears:

1. Detection - the failure is noticed through an alarm, an operator or monitoring
2. Notification and response - the right technician or specialist is called out and is on site or logs in remotely
3. Diagnosis - the cause is found; in OT often the longest phase for intermittent faults
4. Logistics - waiting for spare parts, tools, a permit or an external supplier
5. Repair - replacing, repairing or reconfiguring, for example restoring a PLC program from a backup
6. Test and restart - functional test, possibly release by quality or safety, and ramp-up to nominal production

In many plants most of the time is not spent on the actual repair work but in phases 2, 3 and 4: waiting for the right person, searching for the cause and waiting for a part.

📈 Why does MTTR matter for availability?

MTTR and MTBF together determine availability:

Availability = MTBF / (MTBF + MTTR)

If you use only the active repair time for MTTR, the result is called inherent availability. If you also count waiting time, logistics and detection, the result approaches the availability that production actually experiences. Here too, the MTTR definition determines the outcome.

Take a machine with an MTBF of 1,000 hours. With an MTTR of 8 hours, availability is 1,000 / 1,008 = 99.21%, roughly 70 hours of downtime per year in continuous operation. Bring the MTTR down to 2 hours and availability rises to 99.80%, leaving about 17.5 hours of downtime, without the machine failing even once less.

Availability is also one of the three factors of OEE, so a lower MTTR directly raises OEE. MTTR is also a baseline figure in SLAs, business continuity plans, asset management and the capacity planning of maintenance teams and spare parts.

🔐 What role does MTTR play in functional safety and cybersecurity?

Functional safety. In IEC 61508 and IEC 61511, restoration time is a parameter in calculating the probability of failure of a safety function (SIL). While one channel of a redundant safety instrumented system is under repair, the installation runs with less protection. Designers therefore calculate with an assumed restoration time, and the operator has to achieve it in practice through spare parts, procedures and compensating measures.

Cybersecurity. For security incidents the emphasis shifts to detection and response time. According to IBM’s Cost of a Data Breach report for 2025, it took on average 241 days to identify and contain a breach, the shortest lifecycle in nine years. After a ransomware attack on OT, recovery can take days to weeks, because engineering workstations, historians and PLC programs have to be restored cleanly one by one. Under the Dutch Cyberbeveiligingswet (the NIS2 implementation, see NIS2), a significant incident must also be reported with an early warning within 24 hours and a full notification within 72 hours, while recovery is often still under way.

🔄 What is the difference between MTTR, MTBF, MTTF and RTO?

The relationship between MTTR and RTO is the most useful in practice: the RTO is what you promise, the MTTR is what you actually achieve. If the measured MTTR is structurally above the RTO, the recovery plan is not realistic.

🏭 How do you reduce MTTR in an OT environment?

• Measure honestly first - record start and end times per phase in the CMMS or derive them automatically from machine states in the historian, instead of estimating afterwards
• Speed up detection and diagnosis - good alarming, condition monitoring and diagnostic data from smart field devices point to the cause faster
• Stock critical spare parts - use an FMEA or criticality analysis to determine which parts have long lead times, especially for legacy systems whose parts are no longer manufactured
• Keep backups current - of PLC programs, HMI projects and configurations of switches and drives, with a tested restore procedure
• Make specialists available remotely - securely designed remote maintenance saves suppliers travel time
• Standardise and document - fault logs, work instructions and uniform hardware shorten diagnosis and repair
• Learn from every failure - a root cause analysis prevents recurrence; predictive maintenance and TPM shift unplanned repairs to planned maintenance
• Build in redundancy where it counts - with redundancy a standby component takes over and the restoration time for the process becomes almost zero, while the repair happens in the background

❓ Frequently asked questions

What is a good MTTR?

A good MTTR does not exist as an absolute number, because it depends on the type of installation, the definition used and the cost of downtime. For a simple machine fault an MTTR of under one hour is achievable, while restoring a large process unit can take days. Compare your MTTR mainly with your own history, with the RTO and with similar installations.

Does MTTR include detection time?

Whether detection time is included in MTTR depends on the definition used. IEC 61508 and the IEC dependability vocabulary use MTTR for mean time to restoration, including detection, whereas many maintenance systems and ISO 14224 measure only the repair time. Fix the definition before you compare MTTR figures.

How are MTTR and MTBF related?

MTTR and MTBF together determine availability through the formula MTBF / (MTBF + MTTR). A higher MTBF means fewer failures, while a lower MTTR means a shorter recovery per failure. Both raise availability, but MTTR is often quicker to improve because it depends on organisation, spare parts and knowledge rather than on a different design.

What does MTTR mean in a SOC?

In a Security Operations Center, MTTR usually stands for mean time to respond: the average time between detecting and containing a security incident. Together with MTTD (mean time to detect), this MTTR shows how quickly a SOC notices and stops threats. It is therefore a different measurement from the maintenance MTTR of a machine.

What is the difference between MTTR and RTO?

MTTR is a measured average of the actual recovery time after failures or incidents. The RTO (Recovery Time Objective) is a predefined target for the maximum recovery time of a process or system. A measured MTTR above the RTO shows that the recovery plan needs to be tightened.

How do you record MTTR reliably?

You record MTTR reliably by capturing fixed timestamps per failure for occurrence, detection, start of repair and release, preferably automatically from machine states or the CMMS. Times entered manually after the event tend to be optimistic and miss waiting time. Also record the cause of each failure, so you can see which phases and failure types drive the MTTR.

📌 In summary

MTTR is the average recovery time after a failure and, together with MTBF, determines how much availability an installation delivers. If you define MTTR unambiguously, measure it per phase and work deliberately on detection, diagnosis, spare parts, backups and knowledge, you raise availability and OEE without the machine itself having to become more reliable.