Ask anyone on a shop floor to name their worst downtime problem and they’ll describe a breakdown. A gearbox that failed, a controller that faulted out, a line down for two hours while maintenance sourced a part. That’s the loss people remember, because it was loud, it stopped the whole conversation, and someone stood around watching it happen.
Nobody remembers the sensor that mis-triggered forty times last Tuesday, twenty seconds each, or the part that needed a manual re-seat every fifteen minutes on the second shift. Those stops are too small to register as an event in anyone’s memory. They’re also, on most floors, the biggest source of lost capacity nobody’s ever added up.
The two minute stop that isn’t an event
A two minute stop looks like nothing next to a two hour breakdown. Compare them side by side and the breakdown wins every time, a hundred times longer by the clock. But a two minute stop that happens fifteen times a shift is thirty minutes of lost run time every single day, and it stays invisible precisely because no individual instance was ever big enough to complain about. A supervisor doesn’t call a meeting about a stop that lasted less time than it took to read this sentence. They call a meeting about the gearbox.
That asymmetry is the entire reason minor stops go unmeasured on a floor running a clipboard or a memory-based system. Nobody writes down a two minute stop because nobody’s standing there with a stopwatch when it happens, and even if someone tried, fifteen entries a shift per machine would bury the log in noise before lunch.
Why they add up past the breakdowns
Total the minutes instead of counting the events and the picture reverses. A machine that loses six hours a month to one dramatic breakdown and four hours a month to two hundred small stops has a bigger minor-stop problem than breakdown problem, even though the breakdown is the only one anyone’s ever discussed. Six Big Losses frameworks have called this out for decades under the label “idling and minor stoppages,” it’s one of the original six, sitting right next to breakdowns as its own category, not a footnote to it. The framework put it there because the people who built it were looking at the same asymmetry: loud losses get fixed, quiet losses accumulate.
A plant that only chases its breakdowns is chasing a fraction of its actual downtime. The rest sits in a category nobody’s ever measured well enough to rank.
Where the line sits between a blip and a real stop
Not every micro-pause is meaningfully downtime, and treating every single one as an event to investigate creates a different failure: a system that interrupts someone constantly for stops too trivial to matter, which teaches people to distrust the whole thing. A part clearing a sensor with a quarter-second flicker isn’t downtime in any useful sense. The fix is a graded floor, not a human judgment call made fresh every time a machine hiccups.
A sensible structure runs three rungs. A blip under a few seconds is sensor noise and never counts as a stop at all. Below that, a configurable ignore floor, typically a few seconds, catches pauses that happened but are too short to matter even automatically, they’re not logged as downtime. Above the ignore floor sits the minor stop threshold, usually somewhere in the ten to thirty second range, and anything under it gets logged automatically as a minor stop, no human asked, but it still counts in every downtime total and shows up in the Pareto under its own label. Anything longer than that is real downtime and needs a person to tag a reason.
The threshold matters more than it looks. Set it too low and every twitch on the line becomes a logged event, drowning the real minor stops in noise. Set it too high, five minutes because nobody wants to code that many stops, and a plant starts calling real downtime a minor stop just to make the queue shorter, which hides exactly the loss this whole structure exists to surface. Ten to thirty seconds is usually the right range. Minutes usually isn’t.
Seeing minor stops without a clipboard
The only realistic way to catch a two minute stop is to have the machine report its own state changes, run to stopped and back, automatically. A clipboard system can catch the fifteen minute changeover because someone’s standing there for the whole thing. It cannot catch forty three second events spread across an eight hour shift. Nobody’s writing that fast, and nobody’s reconstructing it accurately from memory hours later either.
Once a machine’s stops are captured automatically, minor stops show up as their own row on the Downtime Pareto, ranked by total minutes right alongside breakdowns, changeovers, and every coded reason. That’s the point where a plant usually has its first real look at where minor stops actually rank. Sometimes it’s near the top. A machine with a recurring feed jam every few minutes can lose more capacity to minor stops in a week than it loses to its one real breakdown that month, and there’s no way to know that without the row existing to compare against.
What to do once you can see them
A minor stop row that’s unusually large on one specific machine is a signal worth investigating even though no individual instance triggered a reason code. Look for a pattern in when they cluster, a specific shift, a specific product, right after a changeover before the process settles in. That pattern is often more diagnostic than any single coded reason would have been, because it points at a mechanical or process issue that’s happening constantly at low intensity instead of once at high intensity.
The fix is rarely dramatic. A sensor that needs recalibrating, a fixture that’s slightly out of alignment, a feed rate that’s a touch too aggressive for one specific material. None of those show up as a breakdown. All of them show up as a minor stop count that’s higher on one machine than its neighbors, once someone’s actually looking at the number.
Quick recap
- A two minute stop is invisible in the moment but adds up fast when it repeats dozens of times a shift.
- Total minutes lost, not event count, is what reveals minor stops often outrank the breakdowns everyone talks about.
- Grade every stop on a ladder: blip, ignore floor, minor stop threshold, then real downtime, instead of asking a human to judge each one.
- Keep the minor stop threshold in the ten to thirty second range. Minutes usually means real downtime is hiding behind an automatic label.
- Automatic capture from the machine itself is the only practical way to catch stops this short and this frequent.
- A high minor stop count on one machine is a real signal worth chasing, even with no individual reason code attached to any of it.