I want to show you something about your downtime that almost nobody measures.
Pick the last time a line went down hard in your plant. Now split that stoppage into pieces. How long until someone was standing at the machine? How long until they knew what was wrong? How long did the actual repair take? How long to get it running again?
On a lot of floors, the repair is not the big piece. The big piece is the stretch in the middle, where a technician is standing at the machine and does not yet know what to fix. Sometimes they are reading. Sometimes they are calling around. Sometimes they are waiting for the one person who has seen this before to drive in.
That middle stretch is where this guide focuses, because it is the part most downtime programs never touch.
What is unplanned downtime?
Unplanned downtime is any time a machine or line stops producing when it was scheduled to run, because something failed rather than because you chose to stop it. Planned stops like PMs and changeovers are on your schedule. Unplanned downtime is the phone call nobody wants, and every minute of it comes straight off your output.
The cost is more than lost parts per hour. Overtime to catch up, expedited freight, scrap from a bad restart, a late shipment to a customer who remembers. You already know the number for your plant is big. The question is where to push to make it smaller.
Where do downtime minutes actually go?
Every stoppage has five parts: response (someone gets to the machine), diagnosis (they figure out what is wrong), parts (they get what they need), repair (the fix itself), and restart (the line runs good parts again). Most improvement work goes into parts and repair. Diagnosis is usually the biggest and least measured.
Here is why. Repair time is visible. You can see a tech turning wrenches, and you can train them to turn wrenches faster. Parts are visible too. You can stock critical spares and watch the shelf.
Diagnosis is invisible. It looks like a technician standing still, or scrolling a PDF, or on the phone. It does not show up as its own line in most downtime reports. It just makes every event longer.
And diagnosis time depends almost entirely on who is on shift. A veteran who has seen the fault before might walk straight to the cause. A newer tech on the same fault might spend hours getting there. Same machine. Same fault. Very different downtime.
Why is downtime getting worse on so many floors?
Because the people who shorten diagnosis are leaving. Decades of pattern recognition, the kind that lets a veteran hear a failing bearing or know which fault on which press means one loose connector, is retiring faster than plants can pass it on. The machines have not changed. The answers walking the floor have.
Look at who is carrying that knowledge today.
54 years is the average age of a maintenance professional.
16% of the maintenance workforce is under 40.
When your most experienced tech is off shift, on vacation, or retired, the diagnosis window on their machines gets longer. That is not a hiring problem you can solve next quarter. It is a downtime problem showing up right now. The full math is in the hidden cost of downtime from retirements.
Six steps to reduce unplanned downtime
These are in order. The first two cost nothing and you can start this week.
1. Measure the wait, not just the repair
For every stoppage, log five timestamps: machine stopped, technician arrived, cause identified, repair finished, line running. Do it on a whiteboard if you have to. After a month, the gaps tell you exactly where your minutes go. Many teams are surprised by how big the diagnosis gap is.
2. Find your one-person machines
Make a list of every machine that only one or two people can reliably fix. Be honest. Then look at when those people are not on shift: nights, weekends, vacations. That list is your downtime risk, ranked. It is also your shopping list for the next four steps.
3. Put the answer at the machine
The fastest diagnosis happens when the tech on shift has the veteran’s reasoning in their hand at the moment of the fault. Not in a binder in the office. Not in someone’s head across town. On the floor, at the machine, on the phone they already carry. This is the single biggest lever on the diagnosis window, and it is what an AI maintenance agent does on a real shift.
4. Capture every fix as it happens
A fault you solved once should never take as long the second time. But on most floors, the lesson from last month’s repair lives in one person’s memory. Record each fix when it happens: the fault, what was checked, what fixed it. Over time your repeat faults, which are often the majority, get faster on every shift. There is a practical playbook in capturing tribal knowledge before it retires.
5. Make your PMs match what actually fails
Your PM schedule should be built from your own failure history, not only the OEM manual. Look at what broke over the last year and ask whether a PM would have caught it. Add the checks that would have. Retire the ones that never find anything. Every failure you prevent is a diagnosis you never have to make.
6. Fix your work order records at the source
Steps 4 and 5 only work if your records say what really happened. A work order that reads “fixed sensor” tells the next tech nothing and tells your PM planner nothing. The fix is to write the record from the job itself, with the fault, the checks, the cause, and the parts, at the moment the job is done.
How does AI reduce unplanned downtime?
AI shortens the diagnosis window. An AI maintenance agent reads the fault, the PLC logic, and your plant’s own history, then walks the technician on shift to the cause step by step. It captures the fix and writes the work order, so the next occurrence is faster. It helps with steps 3 through 6 at once.
That is exactly what we built Jack to do. It handles troubleshooting at the machine, reads and writes PLC code, captures tribal knowledge, and creates and writes all work orders and PMs. Your technicians stay in charge. Jack takes the hunting off their plate.
Here is what that looked like in one sample month at one real plant we serve.
14 hours of downtime avoided in the sample month (estimate).
38 hours of technician time saved in the same month (estimate).
Both figures are estimates, derived from analysis of Jack troubleshooting sessions over that month. And here is what it looks like on a single fault: an 18-year-old technician, alone on a weekend shift, brought a downed robot back online in 30 minutes. A senior-level repair, made by following Jack step by step at the machine. The case study has the full timeline.
Start with your worst line
Here is what I would do if I were you. Run steps 1 and 2 this month. You will end up with a short list: the machines where the wait is longest and the fewest people can fix them.
Then bring me that list. Metis deploys on site, learns your PLCs, documents, and work order history, and is live in weeks with results in 30 days. Your CMMS stays your system of record.
Book a demo and pick the machine on that list you worry about most. That is where I want to start.