Machine downtime: how to record it, analyze it, and reduce it

What machine downtime means

Machine downtime is time when a machine is not producing even though, according to plan, it should be. An injection machine stopped for 40 minutes because a mold heater failed, a packing line waiting for cartons, or a compressor that trips in the middle of the night shift and takes the whole pneumatic line down with it: all of these are downtime, even though their causes could hardly be more different.

The key phrase is should be producing. A machine that stands idle because there are no orders, or because the plant is closed for a holiday, is not in downtime in this sense. Measuring downtime therefore always starts from one reference: planned production time, the time actually allocated to production after breaks and other deliberate stops have been taken out.

Planned and unplanned downtime

Planned downtime is a stop scheduled in advance, such as a break, a start-of-shift meeting, or preventive maintenance that has been put into the production schedule. Unplanned downtime is a stop that happens outside the plan: a breakdown, running out of material, waiting for an operator, or a quality problem that forces the machine to be stopped.

Changeovers sit in a gray zone. They are usually planned, but how long they take depends heavily on how the team works, and within the OEE framework they still count as an availability loss^[1]. There is no single right answer; what matters is a written decision applied the same way on every machine and every shift. If changeovers are sometimes left out of the calculation and sometimes not, the downtime figure will move while nothing has changed on the shop floor.

Minor stops

Between a running machine and a broken one lies a zone that is often missed: the minor stop. A sensor covered in dust, a bottle knocked over on the conveyor, or material jammed in a chute stops the machine for a minute or two, and it runs again once the operator clears it. One event looks trivial. Dozens per shift are not trivial at all. Nakajima separated this loss from equipment failure and classed it as a speed loss rather than an availability loss^[1].

Where downtime sits in OEE

Downtime is the raw material of the availability factor in OEE. ISO 22400-2 defines availability as the ratio of actual production time to the time planned for the production unit^[2]. In other words, every minute of downtime comes straight off the numerator while the denominator stays the same.

Of the six big losses defined by Nakajima, two fall under availability: equipment failure and setup and adjustment^[1]. Minor stops and idling fall under performance. The split is more than bookkeeping. Breakdowns are usually handled by maintenance, changeovers by production and engineering, while minor stops often trace back to machine design or material quality. Lumping all three into one "downtime" number leaves it unclear who should act.

Hansen stresses that OEE only becomes useful for improvement when its losses are broken down to causes that can be acted on^[3]. For the availability factor, that breakdown depends entirely on the quality of downtime records.

How to record downtime properly

Most problems in downtime analysis are really recording problems. Data written from memory at the end of a shift, with rounded durations and guessed reasons, does not get better by being analyzed carefully. Good recording separates two questions: when and for how long the machine stopped, which the machine itself should answer, and why it stopped, which a person has to answer.

Detecting stops and restarts automatically

Stop and restart times are most reliably read straight from the machine: a status signal from the PLC, a production counter that stops incrementing, or motor current falling below a load threshold. That way every event is recorded with an accurate timestamp, including the ones at two in the morning when nobody had time to write anything down. Operators are no longer asked to remember times, only to explain causes.

A duration limit: when a stop counts as downtime

Once automatic recording is running, a practical question comes up: does a 20-second stop need a reason? Usually not. Many plants set a minimum duration threshold, for example five minutes. Shorter stops are recorded as minor stops and totaled automatically, while longer ones count as downtime and must be given a reason. The right threshold depends on the machine; a fast packing line may use a shorter limit than a large press. What matters is that the limit is set once, written down, and not quietly changed when the numbers look bad.

A short list of reason codes

Reason codes turn a list of events into data that can be grouped. The first temptation is usually a very complete list with dozens of options. The result is the opposite of what was intended: an operator who has to scroll through a long list in the middle of a problem will pick the first option that looks plausible, or "other". A two-level structure works better. The first level holds a few broad categories that are easy to choose; the second level details the causes that occur most often on that machine.

Who confirms the reason, and when

The most accurate reason comes from the person standing near the machine, at the time of the event or right after it. In practice, the operator picks a reason when the machine stops or when it is restarted, and the technician completes or corrects it if the repair turns up a different cause. The supervisor then reviews any events still missing a reason before the shift ends. The longer the gap between the event and the reason being entered, the more guesswork ends up in the data.

Downtime measures worth tracking

Total downtime minutes alone are not enough to choose an action. Two machines with the same total downtime can have very different problems: one stops twice for a long time, the other stops thirty times for a short time. That is why three measures are best read together.

MTTR, which is also one of the indicators in ISO 22400-2^[2], is the bridge between production data and maintenance data. From the production side, downtime from a breakdown runs from the moment the machine stops until it runs again. From the maintenance side, that time breaks down into waiting for a technician, diagnosing, waiting for spare parts, repairing, and testing. When downtime records are linked to work orders in a CMMS, the team can see which part takes longest.

The figures below are illustrative, not data from any particular plant. A packing line runs 26 days a month, two shifts a day, with 450 minutes of planned production time per shift. Its planned production time is 26 × 2 × 450 = 23,400 minutes. With a five-minute threshold, 60 downtime events are recorded.

1. 1Downtime percentage = 1,200 ÷ 23,400 × 100% = 5.1%.
2. 2Availability = (23,400 − 1,200) ÷ 23,400 = 22,200 ÷ 23,400 = 94.9%.
3. 3Average duration = 1,200 ÷ 60 = 20 minutes per event.
4. 4Average recovery time for mechanical failures = 156 ÷ 4 = 39 minutes, measured from the machine stopping until it runs again. MTTR in the maintenance sense will be shorter if part of that time was spent waiting for a technician.

Notice that the ranking by duration and the ranking by frequency are not the same. Material jamming on the conveyor happens most often, 25 times, but each event is short. Mechanical failures happen only four times, but each one lasts longest. These two kinds of problem need different approaches.

Pareto analysis: choosing the reasons that matter most

Juran popularized the Pareto principle in quality management: in many problems, a small share of causes (the vital few) accounts for most of the effect, while the rest is spread across many small causes^[4]. A Pareto chart shows this directly: reasons are sorted from largest to smallest, so the eye goes straight to the first few bars.

In this example, the top two reasons account for 720 of 1,200 minutes, or 60 percent of all downtime. A team working on those two reasons touches most of the problem, while a team spreading its attention evenly across all five will move slowly on every one of them.

A few habits make a Pareto chart more honest. Build it by duration and by frequency, and compare the two. Build it per machine, not only per plant, because the largest reason on one machine can disappear in the aggregate. And use a long enough period, such as a month, so that one unusual large event does not dominate the picture.

Finding the root cause by asking "why" repeatedly

A Pareto chart shows where to look, not what to fix. For that, Ohno described the practice at Toyota of asking "why" up to five times about a problem, so that what is found is the real cause rather than the nearest symptom^[5]. His own example, too, starts from a machine that stopped.

Take the second reason in the example above, material jamming on the conveyor. Why does material jam? Because packs arrive skewed at the guide. Why are they skewed? Because the spacing between packs is uneven. Why is it uneven? Because the upstream conveyor belt slips at high speed. Why does it slip? Because belt tension was never checked after the last replacement. Why was it not checked? Because a belt tension check is not on that line's routine maintenance list.

The last answer is something that can be changed permanently: adding one item to the maintenance checksheet. Compare that with the first answer, which only produces the instruction "operators need to clear jammed packs faster". The number five is not a fixed rule. Stop when the answer points to something that can be fixed and that, once fixed, prevents the same event from recurring. The proof is in the data: the frequency of that reason should fall in the months that follow.

Shortening changeovers with SMED

In many plants with a high product mix, changeover is the largest downtime reason, as in the example above. The best-known method for reducing it is SMED (Single-Minute Exchange of Die), developed by Shingo. The name refers to a changeover target in single-digit minutes, that is, under ten minutes^[6].

The core of SMED is separating two kinds of setup work. Internal setup can only be done while the machine is stopped, such as removing the old mold and mounting the new one. External setup can be done while the machine is still running, such as preparing the next mold, tools, and material beside the machine. Shingo observed that much work that is really external gets done after the machine has already stopped^[6].

The first step of SMED costs almost nothing: record one changeover from start until the first good part comes out, then mark every task as internal or external. Downtime data helps here in two ways. It shows which machines and which types of changeover take the most time, and afterwards it proves whether the average changeover duration really fell, not just on the day when everyone was being watched.

Shortening response time

Not all downtime is repair time. A large share sometimes goes on something simpler: the operator looks for the supervisor, the supervisor phones a technician, the technician is in another building and only finds out twenty minutes later. In the example above, the gap between the 39-minute recovery time and the actual repair time is this kind of loss.

This is where andon comes in. In the Toyota production system, the andon is a board or light that shows where a line has stopped, so that help can come to the right spot quickly^[5]. Modern versions send a call to the right person according to the type of problem and record when the call was made, when it was answered, and when it was closed. With that data, waiting time can be separated from repair time, and each can be improved in its own way: the first through escalation rules and staffing, the second through skills, procedures, and spare parts availability.

Reducing downtime step by step

1. 1Write the definition down. Set what counts as planned production time, how changeovers are treated, and what duration limit separates downtime from minor stops.
2. 2Record stops and restarts from the machine. Start with the few machines that most determine output, then expand once the data is trusted.
3. 3Build two-level reason codes. Use the existing event history as the basis, keep the first level short, and decide who enters reasons and when.
4. 4Review the Pareto regularly. Discuss it per machine, by duration and by frequency, in a short weekly meeting with production and maintenance.
5. 5Pick one or two top reasons. Trace their root cause by asking "why" repeatedly, or apply SMED if the reason is changeover.
6. 6Separate response time from repair time. If waiting for technicians or material turns out to be large, fix the call and escalation flow first.
7. 7Verify with data, then repeat. Make sure the reason being worked on really falls, standardize the change, then go back to the Pareto to choose the next reason.

Common mistakes in managing downtime

• Recording from memory at the end of the shift. Durations get rounded, short events disappear, and reasons are filled in with whatever is easiest to remember. Data like this tends to show a few big breakdowns and hide dozens of small interruptions.
• Letting "other" become the biggest reason. It means the code list does not match what actually happens at the machine, or reason entries are not being reviewed. This category needs regular checking and splitting when it grows.
• Blaming operators. When downtime data is used to find who is at fault, reasons get filled in with the safest option, not the most accurate one. Most recurring downtime is rooted in the machine, the material, the method, or how work is organized, and it can only be found when people feel safe reporting it.
• Changing definitions without recording the change. Raising the duration limit or moving changeovers into planned downtime improves the numbers instantly, without adding a single minute of production.
• Collecting data without reviewing it. Automatic recording that is never discussed in a regular meeting only produces reports. Its value appears when the data is used to choose actions and check their results.

Conclusion

Machine downtime rarely has a single cause. It is a collection of breakdowns, changeovers, late material, and minutes spent waiting. Plants that manage to reduce it usually do not start with new technology but with honest data: stops and restarts recorded by the machine, reasons given by the people who saw the event, and a definition that does not change from month to month.

From that data, the path is fairly clear. A Pareto chart shows the few reasons that matter most. Repeatedly asking "why" finds the root cause of failures and disruptions that keep coming back. SMED shortens changeovers, and a clear response flow cuts waiting time. None of these steps removes downtime completely, but each can be measured, and so its result can be proven.