How to reduce MTTR in manufacturing: fix the hour nobody measures.
The average plant repairs an unplanned stop in 65 minutes, and most of that hour is not repair at all. A practical playbook for cutting MTTR by attacking diagnosis, the phase most plants do not even measure.
Mean time to repair is the metric plant managers stare at and the one they have the least leverage on, because the standard playbook (more spares, more training, faster dispatch) attacks the smallest part of the clock. This post is about the biggest part: the share of every repair that is spent finding the fault rather than fixing it, and the five levers that actually shrink it.
What is MTTR and how is it calculated?
MTTR is total unplanned repair time divided by the number of repairs over a period. If your line logged 20 stops last month and 22 hours of repair time, your MTTR is 66 minutes. The benchmark: Siemens' True Cost of Downtime report (2024) puts the average plant at a 65-minute MTTR across 25 unplanned stops per month. If you are near that number, you are average, and average is expensive: at the same report's cost figures, each month of average performance is 27 hours of lost production.
Where does the repair hour actually go?
Reliability engineering splits repair time into phases, and the split is the whole story. IEC 60050-192 defines active repair time as fault localization plus correction plus check-out. MIL-HDBK-472 and decades of maintainability studies put hands-on correction at only 30 to 40 percent of the total. The rest is detection, diagnosis, and verification: figuring out what is wrong, and proving the fix worked.
| Phase | Share of repair time | What most plants do about it |
|---|---|---|
| Detection | ~10% | Andon, alarms (usually covered) |
| Diagnosis / fault localization | ~40–55% | Almost nothing |
| Correction (hands-on repair) | ~30–40% | Spares, training, dispatch |
| Verification / check-out | ~10–15% | Almost nothing |
Read the table again with a manager's eye: nearly every dollar plants spend on MTTR targets the one phase that is already the smallest. The diagnosis phase, the biggest single block of the clock, usually is not even measured separately. That is the hour nobody owns.
The five levers that actually cut MTTR
- 01Measure the split. Log diagnosis time separately from repair time for one month. The number will justify everything else on this list.
- 02Give techs a systematic fault-finding method. A written, ordered procedure (LEDs, comms, power, I/O, forces, fault logs, logic trace, verify) turns the diagnosis lottery into a process.
- 03Make the control logic legible. Most diagnosis time on PLC-controlled equipment is spent working out what the program expects. Documentation that explains what each routine does, generated and kept current automatically, removes the archaeology.
- 04Ground diagnosis in live controller data. A theory confirmed against live tag values in seconds replaces a walk to the panel per candidate cause. This is where AI for PLC troubleshooting earns its keep: it reads the whole program and checks its reasoning against the running controller.
- 05Capture what the fix taught you. Every resolved fault that lives only in one technician's memory will be re-diagnosed from scratch by the next shift. Version the insight with the code.
MTTR vs MTBF: which should you attack first?
MTBF (mean time between failures) is about preventing stops; MTTR is about surviving them. Prevention programs are multi-year capital efforts. The diagnosis share of MTTR, by contrast, is software and method: it can move within a quarter, without touching the machines. For most plants the fastest downtime win available is cutting the 60 to 70 percent of repair time that is not repair.
The arithmetic is compelling. At the average 25 stops and 65-minute MTTR, cutting diagnosis in half saves roughly 8 hours of downtime per month, and at published downtime costs that is somewhere between $290,000 and $18 million a year depending on your industry. Price your own number with the calculator below; every default is sourced.
Price your downtime hour with the free calculator →The eight-step PLC troubleshooting method →AI PLC troubleshooting: how the diagnosis hour becomes minutes →More from the blog

Why industrial AI must understand the entire production line, not just one PLC.
Production lines are rarely single-vendor. A stopped machine on an Allen-Bradley PLC can be waiting on a permissive that only makes sense once you look at the Siemens PLC next to it. What mixed-vendor line context means, why it is different from simply supporting multiple PLC vendors, and how AI can trace a fault across both sides of that handshake.

The three generations of AI for PLC work: chatbots, file-aware AI, and live-plant AI.
AI for PLC work splits into three generations: chatbots that understand PLC concepts, file-aware AI that understands your project, and live-plant AI that understands what the automation system is doing right now. Knowing which one you are looking at changes what you can ask it.

What is PLC AI? A guide to AI for PLC programming and industrial automation.
PLC AI is not one product category. It is five, and picking the wrong one costs you time before you even start. What the term means, what AI can already do with a PLC, the five types of tools on the market, and where PLCs.ai sits among them.
