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

Six things every PLC engineer runs into, and how PLCs.ai finds them automatically.
Cycle-time bottlenecks, dead code, missing interlocks, broken handshakes, race conditions, and signal tracing. Plain-English explanations of concepts that usually take years on the floor to learn to spot.

PLCs.ai vs. pasting your PLC files into ChatGPT.
A general-purpose chatbot can read a snippet of ladder logic. It can't reason across your whole project, simulate a change before it goes live, or guarantee your PLC code never trains someone else's model.

PLCs.ai vs. Siemens Industrial Copilot: which one do you need?
They sound like the same product. They are not. Siemens Industrial Copilot is an authoring assistant inside TIA Portal. PLCs.ai is an intelligence layer over your whole installed base, Siemens and Allen-Bradley alike. Here is an honest breakdown.
