Idling and minor stops are short, self-cleared production interruptions, typically under five minutes, needing no maintenance, where the machine is idling because it is starved or blocked, or briefly stopped by a jam, misfeed, or sensor fault. They are a performance loss, not an availability loss.

This is the loss category almost nobody tracks well. A breakdown gets a work order and a reason code. A 40-second jam that the operator clears with a gloved hand, forty times a shift, gets nothing, and yet those forty clears can outweigh the breakdown. This guide separates idling from minor stops, shows exactly where each lands in the OEE calculation and gives you a way to measure stoppages that are too short to write down. Run your own numbers alongside it in the free OEE calculator.

What counts as a minor stop versus idling?

They are two halves of one of the six big losses and the difference is where the cause lives. A minor stop is an internal interruption: the machine itself hiccups, a jam, a misfeed, a product wedged sideways, a photo-eye that lost the target. Idling is an external interruption: the machine is fine but has nothing to do, either starved of upstream material or blocked by a full downstream buffer.

Both share three traits that separate them from a true breakdown. They are short (the common convention is under five minutes). They clear without a technician, the operator resets, reseats, or waits. And they recur, often dozens of times per shift, which is exactly why their total is large even though each event is trivial. The recurring, root-cause version has its own deep treatment in chronic minor stops; this post is about the whole idling-and-minor-stops category and how OEE treats it.

Idling versus minor stops: internal fault versus external starve or blockOne loss category, two different causesIDLING & MINOR STOPS< 5 min · self-clearedMINOR STOPS · internaljam · misfeedwedged productblocked sensorbad settingIDLING · externalstarved upstreamblocked downstreamwaiting on operatorno materialThe machine is either broken briefly (left) or fine but unfed (right), both are performance loss
The category splits by where the cause lives: minor stops come from inside the machine, idling comes from the line around it. The fixes are different, so the split matters.

Where do idling and minor stops land in OEE?

They land in the performance factor, not availability, and that placement is the whole reason they hide. Availability only counts stops long enough to be logged as downtime. Everything shorter falls through: the machine kept its "running" status, so the clock kept ticking, but it produced nothing during those seconds. The output shortfall shows up as a slower effective rate, which is precisely what performance measures.

The dividing line is a threshold, and it is a convention rather than a law of physics. The widely used rule sets it at five minutes: a stop shorter than five minutes that the operator clears is an idling/minor-stop (performance loss), while a longer stop that needs intervention is an equipment failure or breakdown (availability loss). Many plants tighten this, a common policy is that any stop over two minutes must carry a reason code and therefore counts as downtime. There is no single correct number; what matters is that you pick one, write it down, and apply it the same way every shift, so the split between machine downtime and speed loss stays stable.

The five-minute threshold splitting performance loss from availability lossWhere a stop lands depends on the threshold you setTHRESHOLD ≈ 5 minshort, self-cleared→ PERFORMANCE losslong, needs a technician→ AVAILABILITY lossMove the dashed line and losses migrate between factors, so fix it once and never move it
Bar width is stop duration. Move the threshold and the same physical event changes which OEE factor it hits, which is why a fixed, written threshold is non-negotiable.

Why are these the most under-measured losses on the line?

Because every part of the reporting chain is built to miss them. The stop is over before anyone decides it is worth writing down. The operator looks busy, clearing a jam is work, so the loss is disguised as activity. And no single 30-second event feels significant, so even a diligent operator rounds it to zero. The result is that end-of-shift logs capture the breakdowns and almost none of the idling, and the missing time silently migrates into performance where it looks like the machine is "just running a bit slow."

The math is unkind. If a line takes 30 minor stops averaging two minutes across a 480-minute shift, that is 60 minutes gone, 12.5% of the shift, entirely in the performance factor. A plant chasing a two-point availability improvement while ignoring a twelve-point performance leak is optimizing the wrong end of the line. This is one of the most common reasons a line's net operating time comes in far below what the schedule promised.

There is a second, quieter cost: minor stops train bad habits. When a jam clears in ten seconds, the operator learns to live with it rather than report it, and the line quietly accepts a rate below its own capability as normal. Over months, that accepted rate becomes the reference everyone plans around, and the real capacity of the equipment disappears from the conversation entirely. Comparing actual output against the equipment's rated throughput is often the first time a team sees how much the short stops have cost them.

How do you find stops that are too short to log?

You measure the gaps between good parts instead of asking people to remember stoppages. Any period where the machine should have made a part and did not is a stop, whether or not a human noticed it. Here is the working method:

  1. Anchor the ideal cycle time. Fix the machine's true best repeatable rate per product. Every real cycle longer than that ideal is either a slowdown or a stop hiding as a slowdown. Get this wrong and every later number is wrong.
  2. Capture cycle-level timestamps. Pull part-complete signals from the PLC, a counter, or a sensor so you have the actual gap between consecutive good parts, not a shift total.
  3. Set a stop threshold and a starve/block flag. Decide the duration that separates a minor stop from a breakdown, and tie the machine's inputs so you can tell whether the gap was internal (a fault) or external (starved or blocked).
  4. Bucket every gap automatically. Each gap over the threshold becomes a counted event with a duration and a starve/block/fault tag, no operator memory involved. Details on capturing this cleanly are in OEE data collection methods.
  5. Pareto the events, not just the minutes. Sort by frequency and by total time. The station with 200 twenty-second stops is a design problem; the one with three ninety-second stops is something else. Chase the tall bar first.

How much do idling and minor stops actually cost?

More than most plants believe, because the loss is spread across the whole shift instead of concentrated in one visible event. The table walks a hypothetical bottleneck line through the arithmetic, illustrative numbers, not data from a real plant.

MeasureValue
Planned production time480 min
Minor stops (count × avg)30 × 1.5 min
Idling from starving/blocking18 min
Total short-stop time63 min (13.1%)
Ideal rate60 units/min
Lost units per shift≈ 3,780

Two data points frame why this loss matters at scale:

  • Idling and minor stops are one of the six big losses named in Seiichi Nakajima's foundational TPM work, and are classified as a performance loss because the equipment keeps running while producing nothing usable. The loss taxonomy is documented across the OEE literature at OEE.com's six big losses reference.
  • Real plants run far below theoretical maximums by every measure. The Federal Reserve's G.17 release put U.S. manufacturing capacity utilization at 75.7% in May 2026 a macro reminder that the gap between nameplate and actual output, which short stops widen, is large everywhere.

Do idling and minor stops need different fixes?

Yes, because their causes sit in different places. Minor stops are engineering problems at the machine: a guide rail a millimeter off, a worn gripper, a sensor aimed at a moving target, a product that tips at speed. You fix them by observing many cycles, finding the marginal condition, and designing it out, the same poka-yoke and standard-work discipline you would use on any recurring defect. Recovering faster is not a fix; a stop you clear in ten seconds instead of thirty is still a stop.

Idling is a flow problem in the line, not the machine. A station that is repeatedly starved or blocked is telling you the line is unbalanced or the buffers are wrong, which is a line balancing question. The cure is upstream or downstream: resize a buffer, resequence work, or fix the real bottleneck so the constraint stops choking the stations around it. Treating idling as a machine fault sends maintenance to a machine that was never broken.

Both fixes start with seeing the events, and seeing them is the part paper cannot do. Lines that read stop-level data straight from the equipment, the way Harmony computes true OEE from PLCs and sensors rather than end-of-shift estimates (see the platform), surface the 200 twenty-second stops nobody would ever log by hand. From there it is ordinary problem-solving. For the wider picture of how these losses roll up, read the six big losses and check where your own line sits against a good OEE score.