Micro-Stops: The Invisible OEE Killer

What are micro-stops?

Micro-stops — also called minor stops, short stops, speed losses, sub-5-minute stops, or in the original Japanese TPM terminology chokotei — are stoppages of production equipment that last less than five minutes and are typically resolved by the operator without maintenance intervention. A jam that clears itself after 40 seconds. A sensor that false-triggers and is acknowledged at the HMI. A downstream conveyor that briefly backs up. A material station that runs dry for two minutes between changeovers. Individually, none of these events feel significant. Collectively, they are Category 3 of Nakajima's Six Big Losses framework and, in most plants I have measured, the largest single availability loss on the shop floor — and the one that is almost entirely invisible without automated detection.

I have spent 25 years trying to get manufacturing organisations to take micro-stops seriously. Six Sigma Black Belt at Johnson Controls, global MES lead for 900+ machines and 750+ users across four continents, now Head of Sales at SYMESTIC covering 15,000+ connected machines. I wrote a book in 2025 called "OEE: One Number, Many Lies" and a good part of its thesis is built on this one observation: a plant that doesn't measure micro-stops doesn't know its real OEE — and the number it reports is overstated by 10 to 25 percentage points. That is not a minor accounting error. That is the difference between "we are at 75 % OEE, world-class is 85 %" and "we are actually at 55 % OEE and our entire improvement narrative is wrong."

Why micro-stops matter — the arithmetic of invisibility

The deceptive property of micro-stops is that their impact scales with frequency, not individual duration. A single 3-minute stop looks trivial. A 3-minute stop that recurs every 18 minutes across an 8-hour shift consumes 80 minutes of available time — 17 % of the shift, invisible in every traditional downtime report that uses a 5- or 10-minute logging threshold. Multiply this across a plant of 50 machines and the cumulative loss is larger than every breakdown, every changeover and every planned maintenance window combined. This is not a theoretical observation; it is the finding from almost every OEE audit I have personally run.

The 45-minute breakdown at the top of the table is the event that triggers the maintenance ticket, the RCA, the management escalation, the capital-expenditure proposal. The three micro-stop patterns underneath it cost more availability than the breakdown does — and none of them will show up in a manual downtime log. Plants that focus improvement effort on the top row while ignoring the bottom three are not being lazy; they are being misled by a measurement system that does not capture their largest loss.

The 5-minute threshold — history, convention, and why it is wrong

The textbook definition of a micro-stop as "under 5 minutes" comes from Nakajima's original TPM framework and has been repeated in manufacturing literature for forty years. It was a reasonable threshold in 1980, when logging any stop required a human with a clipboard and the cost of capturing a 30-second event exceeded the analytical value. It is an unreasonable threshold in 2026, when automated machine-state capture via OPC UA or digital I/O can detect a state change in milliseconds at zero marginal cost per event.

The arbitrary-threshold trap. I have watched three generations of manufacturing engineers argue over whether the micro-stop threshold should be 3 minutes, 5 minutes, or 10 minutes. The argument is the wrong argument. The question is not where to draw the line; the question is why the line exists at all. The only reason to impose a threshold on stop detection is if detection is expensive — which was true with manual logging and is not true with automated capture. In every SYMESTIC deployment, we capture every machine state change regardless of duration, and we let the analysis layer decide which stops matter for which purpose. Breakdowns get one workflow, micro-stops get another, sub-10-second blips get filtered out of the operator view but kept in the data for pattern analysis. The threshold is an analytical choice per report, not a data-capture policy. Plants that still have "the 5-minute rule" baked into their data collection are throwing away their most valuable data before it ever reaches analysis.

Why manual downtime logging misses micro-stops

Traditional manual downtime logging systems — the paper-and-clipboard approach, the Excel tracker, even the first-generation MES terminal with a stop-reason dropdown — systematically fail to capture micro-stops. The failure is not a training issue, it is structural, and it has four specific causes that compound to produce the same outcome in every plant.

The fourth failure is the worst because it is invisible to the plant. The first three are behavioural and visible if you audit them; the fourth is baked into the data pipeline and produces a report that looks clean, looks comprehensive, and is systematically missing the largest loss category in the plant. I have audited downtime data from dozens of plants where the aggregated loss report accounted for 94–97 % of the non-running time — and the remaining 3–6 % was labelled "minor / other." That 3–6 %, broken down at the event level, turned out to be more than 2,000 individual micro-stops per month per line. Each one invisible, each one a symptom of something that could have been fixed.

How to detect micro-stops — automated state capture, not operator input

The only reliable way to detect micro-stops is to remove the operator from the detection loop entirely. The operator is an excellent interpreter of cause; the operator is a terrible sensor for event detection under 30 seconds. Modern practice puts the sensing at the machine and the interpretation at the terminal, which is the opposite of the traditional "operator logs everything" model.

The fourth row is where the real analytical value lives. A raw micro-stop report tells you the machine stopped for 90 seconds at 14:37:22. A micro-stop report correlated with the PLC alarm that preceded it tells you the machine stopped because of a specific sensor signal, at that specific position in the cycle, for the 47th time this shift. That is the difference between a data point and a root cause. The Neoperl deployment is the canonical SYMESTIC example of this pattern in production: the plant correlated PLC alarms with micro-stops and quality defects, and the result was a 10 % reduction in stops, an 8 % availability gain, 15 % less scrap and 15 % productivity improvement — from a plant that previously thought its micro-stop problem was "minor."

The improvement pattern — what to do once you can see them

Detecting micro-stops is 60 % of the work; the remaining 40 % is a specific analytical workflow that is different from how breakdowns or setup stops are handled. Breakdowns are one-off events: find the root cause, fix the failure mode, move on. Micro-stops are population problems: they recur hundreds of times and the right response is statistical, not individual. The workflow that actually reduces them has four steps, in order.

The common mistake at step 1 is to rank by cumulative time and miss the rare-but-expensive patterns — or to rank by single-event duration and miss the frequent-but-short patterns. Frequency is the right first cut because micro-stops are a frequency phenomenon: the fix is usually to stop the same event from recurring 40 times a shift, not to shorten any individual occurrence. The common mistake at step 4 is to declare victory after a week. Micro-stop patterns have natural variance; a two-week baseline against a two-week improvement window is the minimum to make a statistically defensible claim. Shorter windows produce false positives that discredit the improvement programme when they revert.

What this looks like across the SYMESTIC installed base

Across the 15,000+ machines connected to the SYMESTIC platform, the micro-stop pattern is consistent enough that I now predict it at the start of every engagement. New customers typically report an OEE number that is 10–25 percentage points too high, because their existing measurement system does not capture sub-5-minute events. Within two weeks of connecting automated state capture, the reported OEE drops — not because performance got worse, but because the real losses finally became visible. Week 3 is where the initial shock turns into action; by month 2, the top-5 micro-stop patterns are identified, countermeasures are in place, and the real OEE starts climbing against an honest baseline.

The named references show the same pattern at different intensities. Neoperl (building materials, fully automated assembly, Müllheim) correlated PLC alarms with micro-stops and defects, landing 10 % fewer stops and 15 % more productivity within months of connection. Brita (FMCG, highly automated packaging in Taunusstein and Bicester) surfaced previously invisible micro-stops through digital signal capture on machines that had been considered "well-understood" for years. Klocke (pharma non-validated, Weingarten) gained 7 additional hours of production time in a single week after micro-stops became visible on previously opaque packaging lines. Carcoustics (automotive moulding and stamping, 500+ machines across Poland and Germany) saw a 4 % reduction in stops and 8 % availability gain on equipment where the plant teams had, in many cases, not believed meaningful micro-stops existed. In every case, the equipment itself did not change. The measurement changed, and the improvement followed.

FAQ

What is a micro-stop?
A micro-stop — also called a minor stop, short stop, speed loss, or in TPM terminology chokotei — is a stoppage of production equipment that lasts less than five minutes and is typically resolved by the operator without maintenance intervention. Examples include a material jam that clears itself, a sensor false-trigger acknowledged at the HMI, a downstream conveyor briefly backing up, or a material station running dry between changeovers. Individually trivial; cumulatively, the largest availability loss in most plants.

Why are micro-stops so damaging despite being short?
Because their impact scales with frequency, not individual duration. A 3-minute micro-stop recurring every 18 minutes costs 80 minutes per 8-hour shift — 17 % of the shift, larger than most breakdowns. Across a 50-machine plant, cumulative micro-stop losses typically exceed the combined loss from every breakdown, changeover and planned maintenance window. And unlike breakdowns, which are visible in every downtime report, micro-stops are almost entirely invisible without automated detection.

What is Category 3 in the Six Big Losses?
Category 3 in Nakajima's Six Big Losses framework is "Idling and Minor Stops" — the official TPM terminology for what we now call micro-stops. The framework classifies the six loss categories into availability impact (categories 1 and 2), performance impact (categories 3 and 4) and quality impact (categories 5 and 6). Micro-stops are classified under performance rather than availability in strict OEE accounting, because they reduce effective cycle rate without registering as a full machine-state stop — though in practice most modern systems now track them as sub-duration availability losses.

Why don't operators log micro-stops manually?
Not because of training gaps — because of arithmetic. Manually classifying a 90-second stop takes about 18 seconds on a well-designed terminal and significantly longer on a poorly designed one. Over a shift with 40 micro-stops, that is 12+ minutes of real work consumed by paperwork about events the operator has already resolved. The operator's rational response is to stop logging, and no amount of training or management pressure sustainably changes that. The problem is not operator behaviour; it is a measurement system that asks the operator to do the work of a sensor.

How do modern systems detect micro-stops automatically?
Four mechanisms, usually combined. OPC UA state subscription captures machine state changes from modern PLCs in milliseconds. Digital I/O gateways capture cycle signals from brownfield equipment with no native digital interface — no PLC modification required. Cycle-time variance detection infers micro-stops from the difference between target and actual cycle times, catching events that pure state signals miss. PLC alarm correlation cross-references each micro-stop with the alarm that preceded it, producing the single most valuable root-cause signal. Together, these four mechanisms capture essentially every micro-stop down to the second.

Why is the 5-minute threshold problematic?
Because it was defined in a manual-logging era when the cost of capturing a short event exceeded its analytical value. In a 2026 automated-detection environment, the cost of capture is effectively zero, and any threshold at the data-collection layer throws away information before analysis. The modern approach is to capture every state change regardless of duration and apply thresholds at the analysis layer per report. Plants that still have a 5-minute threshold baked into their data collection are not filtering noise — they are deleting their most valuable data.

By how much is reported OEE inflated when micro-stops are missing?
In my experience across 15,000+ machines, typically 10 to 25 percentage points. A plant reporting 75 % OEE without micro-stop detection is usually really running at 55–65 % once micro-stops are captured. This is not a small discrepancy. It is the difference between a plant that believes it is approaching world-class and a plant that has a 20-point improvement runway ahead of it. The number that is overstated is almost always the availability component; performance and quality are much less affected by this measurement gap.

What's the right way to analyse micro-stops once you have the data?
Four-step workflow. First, Pareto by event frequency (not cumulative time) — 5–8 recurring patterns typically account for 70 %+ of all events. Second, correlate each top pattern with the PLC alarm and cycle position where it occurs; most cluster at 1–2 specific process steps. Third, apply engineering-level countermeasures to those specific points — sensor recalibration, guide-rail adjustment, cycle-timing change — rather than operator-behaviour changes. Fourth, verify statistically on event-rate per thousand cycles over a two-week window minimum, not anecdotally over a few shifts. Real improvements sustain; false improvements revert within two weeks and discredit the programme.

How does SYMESTIC handle micro-stop detection?
Every machine state change is captured regardless of duration — OPC UA for modern controls, digital I/O gateways for brownfield equipment (1–2 hours per machine, no PLC modification, no production interruption). PLC alarms are automatically correlated with the micro-stops that follow them, producing event-level root-cause data rather than aggregate bars on a chart. The analysis layer lets users apply thresholds per report rather than per data pipeline, so the raw signal is preserved. Typical first-month outcome on a new connection: previously invisible micro-stops become the largest visible loss category, and the top-5 patterns account for the majority of them — the Neoperl pattern, repeated across industries and continents. See SYMESTIC Production Metrics.

Related: OEE · Six Big Losses · Downtime Analysis · Machine Data Acquisition · OPC UA · MTBF · MES · SYMESTIC Production Metrics

About the author

Christian Fieg

Head of Sales at SYMESTIC. 25+ years in manufacturing — maintenance engineer and Six Sigma Black Belt at Johnson Controls, global MES and traceability lead for 900+ machines and 750+ users across China, Mexico, Tunisia, Macedonia, France and Russia, Manager Center of Excellence for the global MES programme at Visteon, Sales Manager MES DACH at iTAC, Senior Sales Manager at Dürr. At SYMESTIC since 2021. Author of "OEE: One Number, Many Lies" (2025). · LinkedIn