Machine downtime tracking is the practice of recording every time a machine stops, how long it was down, and why. A control system can handle the first two parts on its own. The third part, the why, comes from a person tapping a reason on a screen, and that list of reasons is where most downtime programs go wrong. A plant with accurate stop durations and a bad reason list ends up with a number it can report and nothing it can fix. I spent a night shift once standing behind a filler while the operator showed me his reason screen. Forty-one buttons, four columns, two of them scrolling. He had about eight seconds of dead time before the crew needed him back at the infeed. He hit Other. He hit Other most nights. When I asked what the stop actually was, he said the cap chute backs up when the resin comes in cold, and you have to tap the chute twice to clear it. That sentence was worth more than the entire screen, and nothing on the screen said anything close to it. What machine downtime tracking actually records Durations are measurements. Any clock can produce them, and a decent historian will produce them without anyone lifting a finger. The reason is the only part of a downtime record where a human being puts knowledge in. Downtime reason codes are the fixed list of causes an operator picks from when a machine stops, and that list decides what the plant ends up with a record of. Anything the list leaves out has no record at all, one stop at a time. Six months later a different crew on a different shift works out the cold resin thing again, from scratch, at full cost. Why operators pick Other Five reasons, and I have found all five inside one plant. The list was written by someone who does not work the line. It is usually a corporate standard applied to twelve different machines, so it fits none of them. It is too long. Anything past one screen means scrolling and searching in the thirty seconds when the line is down and the operator is needed somewhere else. The words are wrong. The code says Material Handling Deviation, Upstream. The crew says jam at the infeed. Nobody translates under pressure. The codes overlap. When Mechanical Fault and Equipment Failure both exist, picking is guesswork, and two operators split the same recurring stop across two codes so neither one ever ranks high enough to get attention. Nothing ever comes back. The operator has never once seen a fix that started with something he entered. Careful selection has no payoff, so it stops being careful. Other is a sensible answer to a badly built question. Fix the question. How to build a downtime reason list operators will use This is a half-day of work per line, and it is the highest-return half day in any downtime program I have run. One screen. Cap the list at what fits without scrolling. Twelve to fifteen codes per line is where I land on most equipment. Per line, not per plant. A filler and a palletizer stop for almost entirely different reasons. One shared master list guarantees both crews are wrong. Floor words. Write every code the way an operator says it out loud. If the crew says cap chute jam, the button says cap chute jam. Name the event, not the category. Mechanical covers a dozen different stops. Cap chute jam is one thing that happened and one thing somebody can go fix. One code, one fix. If two codes send the same person to do the same job, merge them. If one code covers three different fixes, split it. Top three first. Put the three most common stops on that line in the first three positions. Most shifts never need button four. Pick at the stop, not at the end of the shift. A reason entered at 11 pm from memory is a summary of the night, and summaries lose the small stops that add up to the most time. Prune quarterly. Codes nobody has used in ninety days come off. Anything the crew keeps writing into the comment box goes on. Give the list an owner, and make it easy to change. A reason list that takes a change request and three weeks to add a button is a list that will be wrong for three weeks, and the crew will remember that longer than you will. My rule of thumb: if Other is in the top three reasons on a line, the list is broken. The crew is fine. A one-shift test for your reason list You do not need a project to find out whether your codes work. You need one shift and a notepad. Stand at one line for the whole shift. Every time it stops, write two things: the first thing the operator says out loud in the first ten seconds, and the code that ends up in the system. Nothing else. At the end, put the two columns side by side. Where the words match, the list is doing its job. Where they do not, those are the codes to rewrite, and the operator has already said the words to use. Then do the second half at your desk. Pull last month’s downtime by reason, sorted longest first. Take the top code and ask one question: knowing this, what would we do differently on Monday? If nobody in the room can answer, that code is a category covering several different stops, and each of those stops needs a different fix. What a good reason list is worth Machine downtime tracking is worth exactly what its reason list is worth, and an honest list changes what gets funded. The stop that shows up eleven times a week for four minutes rarely gets a line item, because it never generated a record anybody could see. It just felt like the line running normally. Once it has a name and a count, it becomes the cheapest fix in the building, and somebody will finally do it. Every night your lines produce a short list of things somebody worked out under pressure. A good reason list catches a few of them and hands them to the next shift. A bad one lets the shift end with that knowledge still in one person’s head. The stops repeat either way. The only question is whether the plant is getting smarter about them or just better at counting them. This week: Sit at one line for a single shift and write down what the operator says out loud when it stops, next to what the system recorded. Every stop where the two columns disagree is a code you need to rewrite.