Micro-Stops: The Losses That Never Reach a Report

The losses in your monthly report are the ones someone had time to write down. There is a whole class of loss that, by its nature, nobody ever has time to write down — and it does not disappear from your numbers. It moves somewhere you are not looking.

This article is about micro-stops: what they are, where they hide inside an OEE figure, why they belong to nobody, and how to see them without asking an operator to explain every forty-second pause.

Industrial Reality Check

The Monday production meeting has one item on it that everybody wants to talk about. Machine 12 was down for three hours on Thursday with a hydraulic fault. Maintenance explains the fault, the part that failed, the lead time on the spare. There is a discussion about keeping one on the shelf. It is a good meeting. Something broke, and something will be done.

Nobody mentions that the bar feeder on machine 9 stopped for somewhere between twenty seconds and two minutes, dozens of times a shift, every shift, all week. Nobody mentions it because nobody knows. The operator cleared each one without thinking about it — it is part of running that machine, the way wiping your glasses is part of wearing them. Not one of those stops was long enough to need a reason code. Not one was memorable enough to reach the handover. None of them reached this meeting.

Add them up across a week and they may well be larger than Thursday's breakdown. Nobody in the room can say, because nobody in the room has ever seen them added up.

This is the ordinary state of affairs, not the exception. A plant's loss report is a record of what was memorable and what was long. Micro-stops are neither.

Why the Problem Exists Structurally

Every recording regime has a threshold

Every plant that records downtime has a line below which stops are not recorded — whether or not anybody wrote it down.

Sometimes the line is explicit: stops over five minutes need a reason. That is a sensible rule. Asking an operator to justify every pause would stop production faster than any fault. Sometimes the line is implicit: nobody logs a thirty-second jam because it would be absurd to. Either way the effect is identical. Below the threshold, the plant is blind.

There is no universal line. In the TPM literature, a Kurzstillstand is commonly described as an interruption of less than five to ten minutes, usually cleared by the operator and counted as a performance loss rather than an availability loss. That range is a convention, not a law of nature, and every plant sets its own — usually without noticing it has done so.

Below the threshold, losses migrate

Here is the part that is less obvious. A stop that is not recorded does not vanish from the arithmetic. OEE still has to add up. The time was lost; it has to go somewhere. It lands in one of two places.

Into performance loss. The machine was "running" for the shift, but produced fewer parts than it should have. The OEE report shows a performance figure below 100% and nobody can say why, because the reasons were never recorded. Performance becomes the category where unexplained losses go to be forgotten.

Into the cycle time itself. This is the worse one. If the reference cycle time was set by observing the machine — last year's average, or a stopwatch study on a normal day — then the micro-stops that happen on a normal day are already inside the standard. The machine now appears to perform at nearly 100%, because the standard was calibrated to its bad habits. We call this the cycle time that ate its own losses. Our article on getting a single OEE number from a mixed fleet treats where the ideal cycle time comes from as one of the four decisions that make or break the number; micro-stops are the reason that decision matters so much.

Recall favours the memorable over the frequent

People remember events. A three-hour breakdown is an event. Sixty ninety-second stops are not an event, they are weather. The shift handover records the event; the operator's memory keeps the event; the improvement budget follows the event. A handover written from memory systematically loses exactly this kind of loss.

Nobody owns them

This is the organisational root. A breakdown belongs to maintenance, clearly and correctly. But micro-stops are rarely maintenance problems. They come from part presentation, material variation, a sensor slightly out of alignment, chip build-up, a feeder that needs adjusting rather than repairing, a program that waits on a confirmation it did not need. They sit between maintenance, production engineering, quality and the operators — which in practice means they sit with nobody.

The only role that owns all of those departments' output at once is the person running the plant. Micro-stops are the Werkleiter's loss, because nobody else's job description includes them.

Why Now

It would be reasonable to object that micro-stops matter when a plant is short of capacity, and that most German plants are not short of capacity this year. The ifo Institute reported industrial capacity utilisation at 77.5% in January 2026, well below its long-term average of 83.2%. Destatis reported production in July 2026 down 1.6% on a year earlier, calendar-adjusted.

That objection has it backwards. Low utilisation is when micro-stops hide best. When a plant has slack, a slow machine is absorbed by the schedule. Nobody chases the missing parts, because there was no order waiting for them. The losses are still there — they still cost labour, energy and machine hours per good part — but nothing forces anyone to look.

Two things follow. The first is that cost per part, not volume, is where the pressure is now, and micro-stops are a cost-per-part problem. The second is that when demand returns, the capacity the plant believes it has will not be there, because a share of it was being quietly consumed all along. The time to find it is before you need it.

Architecture Deep Dive

You cannot see micro-stops in a manual log, by construction

This is worth stating plainly because it saves months of wasted effort. A stop shorter than the threshold at which people log stops cannot appear in a log kept by people. No amount of training, discipline or better forms changes that. The only source that sees every stop is the machine.

What the machine can tell you

Many modern CNC controls — and some older ones, with effort — expose their execution state to anything allowed to read it: whether the program is active, ready, interrupted, in feed hold, or stopped, along with alarms and, often, a part counter. The common routes are OPC UA with the umati specifications for machine tools, MTConnect, and Modbus TCP on simpler equipment. Our article on the single OEE number covers what each protocol can and cannot tell you, and the uncomfortable question of what "running" means to a control.

For micro-stops, the requirement is simple to state: state changes at a resolution of seconds, recorded as they happen, not a sample every few minutes. A machine polled every five minutes will report a machine that was running at both ends of a window in which it stopped eight times.

Decide the threshold deliberately

Once the machine is the source, the threshold stops being a practical limit and becomes a choice. Make it one.

A useful pattern is two thresholds:

• Below a short limit — say, a few seconds — ignore it. At that scale you are seeing the control's own rhythm, not a loss.
• Between the short and the long limit — the micro-stop band — count it, time it, but do not ask anyone for a reason.
• Above the long limit, it is a recorded stop, with a reason, exactly as today.

Whatever limits you pick, write them down and do not change them quietly. A micro-stop figure that changes because the threshold changed is measuring your definitions, not your plant.

Do not ask for reasons. Look for patterns.

The reflex, once micro-stops become visible, is to demand a reason code for each. This fails immediately. An operator asked to classify sixty short stops a shift will choose the first option in the list or Sonstiges, and the resulting dataset will be less trustworthy than having no reasons at all.

Micro-stops are diagnosed by pattern, not by testimony. Four cuts do most of the work:

• By machine — which three machines carry most of them?
• By job or part number — do they follow a particular part, material or fixture?
• By time — do they cluster after a tool change, a warm start, a material change, or towards the end of a bar?
• By preceding alarm or state — does each stop follow the same warning, the same feed hold, the same waiting state?

Two weeks is a sensible first window. Once a pattern points at a specific cause on a specific machine, one conversation with the right operator is worth more than a thousand reason codes.

Separate micro-stops from slow cycles

Performance loss contains two different things: stops that were too short to record, and cycles that ran slower than the reference. They have different causes and different owners. A machine that never stops but runs at 85% of its reference speed has a program, tooling or material problem. A machine that runs at full speed and stops forty times a shift has a handling problem. Blend them into one performance number and neither gets fixed.

Anchor the reference cycle time outside the machine's history

If your reference cycle time came from observed averages, take it from somewhere else: the program's own calculated cycle, the machine builder's figure for that operation, or the best sustained run you have on record. The purpose is not to create an impossible target. It is to stop the standard absorbing the losses you are trying to find.

The pattern that works

Pick one bottleneck machine, not the whole plant.

Record state changes at seconds resolution for two weeks, read-only, with no change to how the machine is run.

Set the thresholds on paper before looking at the results, so the results cannot argue you into a convenient definition.

Count and cluster; do not ask for reasons.

Take the top pattern to the people who run the machine, and ask them what it is. Often they know. They may never have been asked with the evidence in hand.

Give the fix an owner by name. A seen loss that nobody owns is only a better-documented loss. We have written about that gap — between a signal and the action it should cause — in our piece on why a dashboard alone changes nothing.

Why Most Micro-Stop Projects Fail to Scale

Reason codes for thirty-second stops. Covered above, and still the most common failure. The dataset fills with Sonstiges within a week.

The whole plant at once. Every machine instrumented, every stop visible, and a report so long that nobody reads past the first page. One machine, found and fixed, is more persuasive than fifty machines measured.

The cycle time is never re-anchored. The plant sees its micro-stops, and its OEE barely moves, because the reference cycle time still contains them. People conclude the exercise was pointless.

Micro-stops handed to maintenance. They are labelled as downtime and routed to the maintenance backlog, where they compete with breakdowns and lose every time, because nothing is broken.

Measured, not owned. The data is correct, the chart is clear, and six months later nothing has changed, because the loss sits between departments and no single person was asked to remove it.

Governance, Security and Co-determination

The works council. Stop-level data by machine and by shift is exactly the kind of data that can be turned into a comparison between operators or between shifts — and in Germany, a technical system capable of monitoring employees' performance is a co-determination matter, to be agreed with the Betriebsrat before it is introduced. The honest design principle is that the unit of analysis is the machine and the pattern, not the person. A micro-stop that follows a particular part number is a process problem. Say that in writing, show the Betriebsrat the data model early, and agree what the data will never be used for. Operators can be the first to benefit: the stops they have been clearing for years become somebody else's problem to fix.

Read-only by design. Seeing micro-stops requires reading machine state. It never requires writing anything to a machine. Decide that before any connection is made, and make sure it is enforced by the connection itself, not by good intentions.

Network placement. A device that reads machine state sits on or near the control network. Decide which segment, who administers it, and whether it can be reached from outside. The answer to the last question should almost always be no.

Decision Framework for Platform Evaluation

1. What is the time resolution of machine state? Seconds, event-driven, or a poll every few minutes? Anything slower than seconds will not see micro-stops.
2. Can you set your own thresholds, and do they apply the same way across every machine and protocol?
3. Does it separate micro-stops from slow cycles, or blend them into one performance figure?
4. Can you cluster stops by job, time and preceding state without exporting to a spreadsheet?
5. Where does the reference cycle time come from, and can you change it without a services engagement?

Executive Summary — Board-Level Interpretation

One. The plant's loss reporting captures stops that are long enough to record and memorable enough to discuss. Micro-stops are neither, so they are absent from the reports that drive improvement spending — while still costing labour, energy and machine hours on every part.

Two. They do not disappear from OEE; they migrate into unexplained performance loss or into the reference cycle time itself. A plant can therefore report a respectable performance figure that is respectable only because its standard absorbed the losses.

Three. Finding them requires machine data at seconds resolution, a threshold decided on paper, and pattern analysis rather than operator reason codes. Plan for the first result from one machine in a few weeks, not from a plant-wide programme. With utilisation low, the pressure is on cost per part — which is exactly the number micro-stops erode.

The failure to guard against at board level is treating micro-stops as a maintenance topic. They are a production-management topic, and they need an owner at that level.

Practical Implementation Checklist

Before measuring anything

• Write down where each machine's reference cycle time came from. If the answer is "last year's average", flag it.
• Pull last month's stop reasons for the bottleneck machine. Count how many are blank or Sonstiges.
• Ask the operators of that machine which stops they clear without thinking about it. Write down the answers verbatim.
• Agree the thresholds — ignore, micro-stop, recorded stop — and agree them with the Betriebsrat.

Two weeks on one machine

• Record state changes at seconds resolution, read-only.
• Count micro-stops per shift and total their duration. Compare the total with the largest recorded breakdown in the same period.
• Cluster by job, time and preceding state. Find the top pattern.

Before extending it

• Take the top pattern to the operators and fix it, with a named owner.
• Re-anchor the reference cycle time for that machine and recalculate OEE both ways.
• Only then choose the next machine.

A note on where we stand

We build software in this space, so we are not a neutral party, and it would be silly to pretend otherwise. This article deliberately does not describe what our software does. Everything above can be done, at a small scale, with the data your machines already expose and a spreadsheet, and it should be judged on that basis.

If you want a quick view of whether your machine data is in a state to support this, we publish a free self-assessment at criussoftware.com/res/kits/readiness/. It asks for a work email, your company name and your consent to be contacted, and returns a scored result. It is a self-check, not an audit.

Questions worth asking in your next review

1. What is the shortest stop your plant records with a reason — and who decided that threshold?
2. Where did your reference cycle times come from: the program, the machine builder, or last year's average?
3. If you counted every stop over thirty seconds on one bottleneck machine for one week, how many would there be — and how many are in the report?
4. What share of last month's stop reasons were Sonstiges or blank?
5. Who in your organisation owns a loss that is too short to be a breakdown?
6. Which improvement did you last fund because it was memorable, rather than because it was large?
7. Does anyone on your floor believe the performance figure — and do they know what is inside it?

The part that matters

A plant does not improve what it cannot see, and it cannot see what nobody had time to write down.

Micro-stops are not hidden by anyone. They are hidden by the reasonable decision not to ask people to record every pause, and by the equally reasonable habit of remembering events rather than weather. The machines have been recording them all along.

The breakdown gets the meeting. The micro-stops get the margin.

Sources

• CETPM, Lexikon: 16 Verlustarten — definition of Kurzstillstände as interruptions typically under five to ten minutes, counted as performance loss. https://www.cetpm.de/lexikon/was-ist-16-verlustarten/7/ (accessed 2026-09-29)
• ifo Institut, press release 10 February 2026, Kapazitätsauslastung steigt langsam. https://www.ifo.de/pressemitteilung/2026-02-10/kapazitaetsauslastung-steigt-langsam (accessed 2026-09-29)
• Destatis, press release 316 of 7 September 2026, production in industry, July 2026. https://www.destatis.de/DE/Presse/Pressemitteilungen/2026/09/PD26_316_421.html (accessed 2026-09-29)

Pick one bottleneck machine and ask its operators which stops they clear without thinking about it. Write the answers down verbatim. That list is the first record your plant has ever kept of the losses it cannot see.