Machine downtime analysis: how to detect micro stops that spreadsheets miss

Machine downtime analysis should capture every time loss that affects production plan execution, including stops that last only a few dozen seconds. If a shift report does not explain why output fell short, start by comparing actual machine cycles with manually recorded downtime. This helps separate breakdowns from micro stops, slower cycles, and waiting time, which often look the same in a spreadsheet—or do not appear there at all.

Manual reporting works well for events that are difficult to miss, such as a breakdown, a longer material shortage, a changeover, or a maintenance intervention. It is much less effective at capturing events that are brief and occur repeatedly throughout a shift.

An 18-second feeder stop, a sensor reset, a temporary blockage at the next operation, or an operator repositioning a part often never makes it into the report. Production resumes after a few seconds, so the event is not treated as full machine downtime. But when it happens dozens of times, the cumulative loss becomes visible in the shift result.

That is why machine downtime analysis cannot rely only on reported downtime. You need a history of equipment states and cycles with enough resolution to detect short interruptions.

In a 2020 study on the impact of micro-stoppages on OEE, Rafał Hubicki, Maria Richert, Piotr Łebkowski, and Natalia Hubicka analyzed three machines used in an aluminum extrusion process. Data was collected automatically over two years. The authors noted that the impact of micro stops is difficult to recognize precisely because they are difficult to record. For the machines studied, including micro stops changed the OEE result by several percentage points. This was the result of one specific process, so it should not be treated as a benchmark for every manufacturing plant.

There is no single time threshold that works for every production environment. On a high-speed line, a 20-second stop can mean many lost cycles. In a process where one cycle takes several minutes, the same event has a different significance.

In the Six Big Losses model, short stops are separated from reduced equipment speed. Idling and Minor Stops covers brief interruptions, while Reduced Speed applies to cycles completed more slowly than the ideal cycle time. Both affect performance, but they usually lead to different diagnoses.

Machine downtime analysis should therefore begin with your own classification rules. Define the threshold at which the system identifies a micro stop, the threshold for longer production downtime, and how events between those thresholds should be handled. If every shift defines a micro stop differently, later comparisons will show differences in reporting rather than differences in machine performance.

You do not need hundreds of PLC variables to get started. Machine downtime analysis primarily requires data that tells you when equipment was running, when it was not producing, and what was happening to cycle time.

You can learn more in our guide to machine data collection and which data is worth collecting: start with states, cycles, counters, stops, and alarms, then add product, work order, batch, or recipe context. Every additional signal should answer a specific question instead of going into the database simply because the controller makes it available.

Assume the reference cycle time is 10 seconds. The machine completes a series of normal cycles, then produces no parts for 40 seconds, after which production returns to its normal pace. That is a short stop.

In the second case, the equipment never stops, but consecutive cycles take 12, 13, and 14 seconds. The report may still show high availability even though performance is dropping.

Machine downtime analysis needs to treat these two situations separately. OEE.com notes that distinguishing Idling and Minor Stops from Reduced Speed often requires accurate cycle data because the sources of these losses are usually different.

With a series of short stops, you examine the point in the cycle when they occur, alarms, and the conditions required to restart production. When cycle times are increasing, you focus on process parameters, load, settings, or machine condition. In a spreadsheet with a single “downtime” column, that distinction disappears.

Choose a machine that limits production plan execution, acts as a bottleneck, or repeatedly comes up in discussions about performance losses.

Separate planned production time from planned downtime and stops that occur while the production plan is being executed.

ISO 22400-1 defines the framework, concepts, and terminology for KPIs used in manufacturing operations management. ISO 22400-2 describes selected indicators, including their formulas, components, behavior over time, and units. Before comparing machines, shifts, or time periods, establish common time definitions and consistent rules for calculating your KPIs.

Machine monitoring should record when equipment stops and restarts without relying on someone to measure the duration manually. The operator is primarily needed to provide context when the controller cannot identify an organizational cause.

An OEE module automates machine data collection, enables stop detection and downtime reason classification, and supports production cycle and micro stop analysis. Machine downtime analysis can therefore be based on the actual operating history of the equipment instead of downtime reconstructed later from memory.

A STOP signal tells you when a machine was not running, but it does not explain why. Machine downtime analysis becomes useful when you connect the event with the product, work order, shift, alarm, and a concise reason category. You can then determine whether the issue occurs randomly or mainly after changeovers, with one specific recipe, or while producing a particular product.

The reason list should be short and unambiguous. If most events end up categorized as “other,” the report will not explain where production time is actually being lost.

Rank the first by total duration and the second by number of events. The same number of lost minutes can come from two 20-minute breakdowns or 120 stops lasting 20 seconds each. Those are two very different problems.

In the previously cited study of three machines, the three dominant causes accounted for approximately 51–63% of total micro-stoppage time, depending on the machine. The purpose of Pareto analysis is therefore to narrow the scope of further investigation rather than treating every event as equally important.

After correcting a setting, repairing a sensor, or changing a work standard, compare the number and total duration of events across subsequent shifts. If the result does not change, the cause may have been defined too broadly, or the intervention may not have removed the source of the problem. A reduction in both event count and total downtime provides a basis for evaluating the result.

A spreadsheet can analyze micro stops very effectively if it receives complete data. The weak point is often the manual data source. If the rule is to record only production downtime longer than five minutes, the spreadsheet will not show 40 stops lasting 30 seconds each. If an operator estimates downtime from memory at the end of a shift, the machine downtime analysis may be mathematically correct while still being based on incomplete information.

A better division of responsibilities is for the machine or system to capture event timing and history, the operator to add context, and the spreadsheet or analytics system to handle aggregation and comparison.

If you want to organize the scope of signals you collect, read our guide to which machine data is worth collecting first. It covers machine states, counters, cycle times, alarms, and the information required for more detailed diagnostics.

Machine monitoring for production purposes tells you whether equipment is running, when it stops, how long a cycle takes, and how actual output compares with the plan. This is the information you need when machine downtime analysis is intended to identify lost production time.

Machine condition monitoring focuses on the technical health of the equipment. Vibration, temperature, current draw, and wear trends become important when you want to determine whether recurring losses have a technical source.

explitia.OEE focuses on production efficiency, stops, downtime reasons, and cycles, while explitia.PDM for Predictive Maintenance extends the analysis with data related to the technical condition of equipment. An increase in the frequency of micro stops can then be compared with changes in machine parameters.

This distinction also helps determine responsibility. If micro stops result from waiting for material, the issue relates to production flow and organization. A recurring sensor alarm directs the analysis toward maintenance or automation. If the number of stops increases alongside changes in technical machine parameters, the equipment condition should be investigated.

Before expanding machine monitoring across the entire facility, choose one machine and one complete shift—preferably equipment whose performance affects line throughput.

Collect an automatic history of machine states and cycles, the part counter, and the operator report. After the shift, compare total downtime in both sources, the number of short events missing from the manual report, the share of slower cycles, and the three most common causes.

If the difference between the automatic and manual records is small, there is no reason to expand the project simply because it is technically possible. If that difference explains the missing output, machine downtime analysis provides a specific basis for defining the scope of continuous monitoring.

With live data, response time also matters. In our article Real-time OEE or a post-shift report?, we show two different uses of production data. A real-time view allows you to respond while the loss is still occurring, while a historical report helps identify recurring events and evaluate the actions already taken.

Machine downtime analysis should lead to a reliable list of losses, including their duration, frequency, and context. Only then can you make a sound decision about how to eliminate the cause.

If short, recurring stops dominate the data, the next step may be our guide on how to minimize micro-downtime in production. It focuses on the causes of micro stops and methods for reducing them, while the analysis described here is primarily intended to detect, measure, and correctly classify them.

Bring your data to the point where you can answer four questions: which machine is losing time, when it happens, how often the event returns, and what it is associated with. At that point, decisions about how to reduce downtime in manufacturing are no longer based on the loudest breakdown from the previous week, but on the actual impact of events on production.

The most accurate approach is to automatically record machine state changes and consecutive cycle times. The micro stop threshold should be adapted to the process and your reporting rules. Manual operator input is more useful for classifying the cause than for measuring event duration.

Classification depends on the methodology you use. In the Six Big Losses model, minor stops are classified as a Performance loss, while longer unplanned downtime affects Availability. When comparing results, use the same rule across all machines and time periods being analyzed.

Start with equipment whose losses affect the output of the entire line, a bottleneck, or a machine with an unexplained gap between planned time and actual output. One area is enough to determine whether more detailed machine monitoring leads to better decisions.

A system can automatically record stops, display Pareto charts, and connect events with products or shifts. Root cause analysis still requires interpretation by people who understand the process. The system shortens the path to the right problem, but the final decision remains with the production and maintenance teams.