MTTR in serial production: how to measure and reduce repair time

When a failure takes 40 minutes, but production loses two hours

In the technician’s report, the failure lasted 40 minutes. In practice, the line was unavailable for almost two hours. Why? The operator noticed the problem after a few minutes. Then they looked for the line leader. The leader passed the information to maintenance. The technician arrived at the workstation, but did not have a complete description of the symptoms. After the repair, the line still had to wait for quality confirmation and restart.

This is how the gap appears between the repair time itself and the real impact of the failure on production. That is why MTTR should not be treated only as a maintenance technician’s performance indicator. In serial production, it shows how efficiently the organization detects a problem, communicates it, diagnoses the cause, removes the failure and restores the workstation to operation.

What is MTTR and why should it not be interpreted too narrowly?

MTTR is most commonly understood as Mean Time To Repair, or the average repair time. In maintenance practice, it usually refers to the average time needed to restore a machine, line or workstation to a condition that allows production to continue.

In maintenance literature and standards, similar indicators are related to maintainability, reliability, technical availability and downtime concepts [1][2]. In serial production, however, it is important to remember that MTTR may be calculated differently depending on the definition adopted by the company.

The most common approaches include:

•  time from failure report to repair completion, 
•  time from machine stop to restart, 
•  time from work order acceptance by maintenance to intervention closure, 
•  time from problem occurrence to stable production recovery. 

Each definition shows something different. If a company measures only the technician’s working time, it may miss delays in reporting. If it measures only machine downtime, it may not know how much time was spent on diagnosis, waiting for spare parts or escalation.

That is why the first step is not to reduce MTTR immediately, but to define what exactly is being measured.

How to calculate MTTR?

The basic formula is simple:

MTTR = total repair time / number of failures

Example:

During one month, the maintenance team handled 20 failures. The total repair time was 600 minutes.

MTTR = 600 minutes / 20 failures = 30 minutes

At report level, this looks clear. The problem starts when data is incomplete or entered manually after the shift. In that case, MTTR may reflect the quality of reporting more than the actual course of the failure.

That is why, for each intervention, it is worth recording not only the repair start and end time, but also:

•  the moment the problem was detected, 
•  the moment the failure was reported, 
•  the time when the information reached maintenance, 
•  the start of diagnosis, 
•  waiting time for spare parts or tools, 
•  the time when the root cause was removed, 
•  the moment the workstation was restarted. 

Only this breakdown shows where time is really being lost.

MTTR and OEE: why average repair time affects availability

OEE consists of three main areas: availability, performance and quality. MTTR has the strongest impact on the first one: availability. If failures last too long or the response is delayed, the line has less time available for planned production.

In TPM and production efficiency analysis, technical downtime is one of the key sources of availability losses [3]. This does not mean that every failure can be eliminated. It means that the organization should know which failures occur most often, how long they last and why it takes so long to remove them.

In serial production, even small differences in MTTR may matter, especially when failures are repetitive. If the same problem occurs several times a week and each intervention takes 10 minutes longer than necessary, the loss quickly becomes significant. It may affect production plan execution, overtime, operator utilization and delivery performance.

That is why MTTR should not be analyzed as a single number. It should be combined with:

•  number of failures, 
•  failure type, 
•  workstation or line, 
•  production shift, 
•  cause category, 
•  spare parts availability, 
•  maintenance response time. 

Only then does the indicator start supporting decisions instead of simply filling a report.

What most often extends MTTR?

In many companies, the problem is not the repair itself, but everything that happens before and around it. A technician may work efficiently, but if the information arrives late or is incomplete, the whole process still takes longer.

The most common causes of high MTTR include:

•  delayed failure reporting, 
•  no clear problem category, 
•  manual communication through several people, 
•  no history of similar failures, 
•  no diagnostic procedure, 
•  searching for technical documentation only after arriving at the machine, 
•  waiting for spare parts, 
•  unclear escalation rules, 
•  closing work orders without describing the cause and solution. 

Research on maintenance management and maintenance performance measurement emphasizes that indicators alone are not enough. They must be connected with decision-making processes, data availability and improvement actions [4].

Otherwise, MTTR becomes a number reported every month, but not necessarily a number that drives better decisions.

How to reduce MTTR without putting more pressure on technicians?

Reducing MTTR is often wrongly understood as “technicians need to repair faster”. This is a risky approach. It may lead to rushing, skipping diagnosis, closing work orders without proper descriptions and seeing the same failure return a few days later.

A better direction is to reduce time that does not add value:

•  waiting for the failure to be reported, 
•  looking for the right person, 
•  passing information manually, 
•  searching for documentation, 
•  recreating failure history, 
•  testing hypotheses that have already been checked before. 

In practice, it is worth starting with four actions.

Set one standard for failure reporting

The operator should not have to wonder who to call or how to describe the problem. Reporting should be simple, fast and repeatable: workstation, status, failure category and optional comment.

The fewer uncertainties at the start, the faster maintenance can begin proper diagnosis.

Separate response time from repair time

If the company measures only the time from repair start to repair completion, it misses earlier delays. It is worth separating:

•  time from problem occurrence to reporting, 
•  time from reporting to response, 
•  diagnosis time, 
•  actual repair time, 
•  restart time. 

This helps identify whether the real problem is technician availability, communication, lack of spare parts, lack of procedures or the technical complexity of the failure itself.

Build work order history

If every failure is closed with only one note — “repaired” — the next intervention starts almost from zero. A well-described work order should include symptoms, checked hypotheses, the cause, actions taken and information on what should be checked next time.

The concept of using experience from previous maintenance actions to support decision-making in future interventions is described in the literature as experience feedback [5].

Implement procedures for repetitive failures

Not every failure requires a procedure. But if the same problem appears regularly, it is worth preparing a diagnostic checklist. This way, a new or less experienced technician does not have to start from a blank page.

A procedure does not replace experience. It helps standardize the first diagnostic steps and reduces the risk of missing obvious causes.

How can AndonCloud support MTTR analysis and reduction?

AndonCloud can support MTTR improvement at several points in the process: from failure reporting, through notifying the right people, to recording intervention history and later data analysis.

Example:

An operator notices a problem at the workstation and changes the status to red. They select the category “mechanical failure” and add a short comment. The system can automatically notify the right people through browser notification, e-mail, SMS or phone call. If the event exceeds a defined time threshold, an alert or repeated notification can be triggered.

In the CMMS module, such an event can create a service work order with an assigned procedure. The technician receives not only information that a problem occurred, but also context: workstation, category, reporting time, operator comment and possibly a diagnostic checklist.

After the intervention, the work order can be completed with the cause, actions taken and conclusions for the future. Over time, this creates a data base that helps analyze:

•  which failures have the highest MTTR, 
•  which workstations generate the most problems, 
•  whether the delay occurs before response or during repair, 
•  which procedures should be improved, 
•  where spare parts, training or changes in preventive maintenance are needed. 

This approach does not guarantee automatic MTTR reduction. It creates the conditions for measuring the problem more accurately, responding faster and making decisions based on data rather than only on after-the-fact reports.

Where to start working on MTTR?

It is usually best not to start with the entire machine park. A better starting point is one line, one group of failures or several workstations with the highest impact on the production plan.

A practical sequence may look like this:

1.  Select the 5–10 most common failures from recent months. 
2.  Check whether you know their actual reporting, response and repair time. 
3.  Separate long failures from frequent failures. 
4.  Define a minimum work order description standard for each category. 
5.  Prepare a checklist for repetitive problems. 
6.  Define alert thresholds for critical failures. 
7.  Monitor MTTR separately by line, failure category and shift. 

In many companies, the first insights appear quickly. Sometimes technicians do not need to “work faster”; they need to receive complete information faster. In another case, the main issue is a lack of spare parts. Elsewhere, the problem is the lack of failure history, which means every shift solves the same issue from the beginning.

MTTR is valuable because it forces specific questions: where does the delay start, what really blocks the repair and what data is needed to respond faster next time?

Summary

MTTR in serial production is not only a maintenance indicator. It measures the efficiency of the whole failure handling process: from noticing the problem, through reporting and response, to diagnosis, repair and production restart.

If MTTR is high, it is not worth starting with pressure on technicians. It is better to check where time is being lost: in communication, lack of data, lack of procedures, waiting for parts or repeating diagnostic steps that were already performed before.

Digital Andon and CMMS can help organize this process. AndonCloud supports fast failure reporting, automatic notifications, alerts, service work orders, procedures and reporting. As a result, MTTR stops being just a number in a report and becomes a practical tool for improving availability and maintenance workflow.

FAQ

What is MTTR?

MTTR, or Mean Time To Repair, means the average repair time. In maintenance, it most often refers to the average time needed to restore a machine, line or workstation after a failure. However, it is important to clearly define when MTTR starts: from failure occurrence, from reporting, from work order acceptance or from the moment the technician starts working.

How do you calculate MTTR?

The simplest formula is: MTTR = total repair time / number of failures. If total repair time in a given month was 600 minutes and the number of failures was 20, MTTR is 30 minutes. In practice, it is important to define which time intervals are included, because repair time alone gives a different result than the full time from line stop to restart.

What is the difference between MTTR and response time?

Response time means how long it takes from failure reporting to action being taken by the right person. MTTR usually refers to the time needed to repair or restore functionality. In serial production, both indicators should be measured separately, because a failure may be repaired quickly, while the response may still be delayed.

How does MTTR affect OEE?

MTTR mainly affects availability, one of the three main components of OEE. The longer a machine is unavailable because of a failure, the less time remains for planned production. High MTTR can reduce OEE, especially when failures affect critical workstations or occur frequently.

What most often increases MTTR?

MTTR is increased not only by technically difficult failures. Delayed reporting, incomplete operator information, lack of diagnostic procedures, searching for documentation, waiting for spare parts or lack of previous intervention history are often just as important. That is why MTTR analysis should cover the entire failure handling process, not only technician working time.

How can MTTR be reduced in serial production?

The best starting point is to standardize failure reporting, automate notifications, split failure time into stages and build work order history. Checklists for repetitive problems and clear escalation thresholds are also helpful. The goal should not be only to repair faster, but to remove delays that do not add value.

Can digital Andon help reduce MTTR?

Digital Andon can support MTTR reduction because it shortens the path from failure detection to notification of the right people. The operator does not need to look for a leader or report the problem verbally. Workstation status, failure category and comment can go directly to maintenance. The actual effect depends on process configuration and team workflow.

How does AndonCloud support MTTR analysis?

AndonCloud can record workstation statuses, reports, notifications, alerts and service work orders in the CMMS module. This allows the company to analyze which failures occur most often, how long response takes, how long repairs take and where delays arise. These data can be used to improve procedures, plan prevention and manage maintenance work more effectively.

Is MTTR enough to evaluate maintenance performance?

No. MTTR is an important indicator, but it should not be analyzed in isolation. It should be combined with the number of failures, availability, MTBF, OEE, cause categories, response time and recurrence of problems. Low MTTR does not always mean a good situation if failures occur very frequently. That is why MTTR should be part of a broader reporting system.

Sources

[1] EN 13306. Maintenance — Maintenance terminology. European Committee for Standardization.

[2] IEC 60050-192. International Electrotechnical Vocabulary — Part 192: Dependability. International Electrotechnical Commission.

[3] Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance. Productivity Press.

[4] Muchiri, P., Pintelon, L., Gelders, L., & Martin, H. (2011). Development of maintenance function performance measurement framework and indicators. International Journal of Production Economics, 131(1), 295–302.

[5] Ruiz, P. P., Kamsu-Foguem, B., & Grabot, B. (2014). Generating knowledge in maintenance from Experience Feedback. Knowledge-Based Systems, 68, 4–20.

[6] ISO 22400-2. Automation systems and integration — Key performance indicators for manufacturing operations management — Part 2: Definitions and descriptions. International Organization for Standardization.

Pre-publication note: technically verify the current editions and bibliographic details of standards and publications before publishing, especially EN/IEC/ISO references.