Two Stories About the Same Downtime

Many food and beverage plants have invested in downtime tracking where operators code each stop. When a line goes down, someone selects a reason, the time is logged, and the data feeds OEE reports, shift meetings and maintenance priorities.

It’s a good system, and it works. But in recent conversations with plants across very different products, from sliced meats to baked goods to canned beverages, the same comment kept coming up: the big stops get captured well, and anything under a minute never gets coded.

That gap matters more than it sounds.

What operator-coded downtime does well

Operator-entered downtime captures something machines can’t: context. A PLC knows the filler stopped. It doesn’t know the line was waiting for packaging material, that a quality hold was called, that the crew was short a person, or that a changeover ran long because the new product needed extra adjustment.

Those reasons are often the most important part of the story, especially for longer stops. They also keep people on the floor engaged with performance, because the people closest to the line are the ones explaining what happened.

What it misses

The limitations show up at the other end of the scale.

A stop that lasts 20 seconds and happens 80 times a shift isn’t something a person can realistically log. The operator is busy clearing the jam and restarting the machine, and by the time the line is running again, the next stop is already coming. Many systems also set a minimum duration for a stop to count, so anything shorter is never even presented for coding.

Even for stops that do get coded, the reason is often chosen quickly and under pressure. Categories like “mechanical” or “other” end up carrying a large share of the total, and the timing is approximate. None of this is a reflection on the people doing the logging. It’s simply the limit of what manual entry can capture on a high-speed line.

Two different stories

Here’s an example drawn from a few packaging lines. The operator-coded data for one line showed about 45 minutes of downtime per shift, with changeovers and one jam category at the top of the list. Clear priorities, clear actions.

Machine data from the same line, same shifts, told a different story. The line stopped around 200 times per shift. About 170 of those stops lasted less than a minute, and together they added up to roughly another 50 minutes per shift. Most of them came from a single station further down the line, where a recurring short fault was stopping the machine for 15 to 30 seconds at a time.

So the largest loss on the line wasn’t in the downtime report at all. It was there in the OEE number, but as reduced performance, the line “running slow” without any explanation of why.

Where short stops hide in OEE

This is a common pattern. When short stops aren’t captured as downtime, their effect shows up as a performance loss instead of an availability loss. The line produces less than it should during run time, and the numbers say so, but nothing points to a cause.

As a result, improvement work tends to focus on the stops people can see in the downtime list, which are usually the longer ones. Meanwhile, the performance loss, which can be just as large or larger, gets treated as a general speed issue rather than a specific, fixable problem at a specific station.

Letting them work together

The most effective setups use both, each for what it’s good at.

Machine data captures every stop automatically, with exact timing, the machine state and the fault code. Short stops are counted, grouped by station and pattern, and summarized without anyone having to log them. Starved and blocked stops are separated from stops caused by the machine itself, so the loss is attributed to the right place.

Operators are then asked for context only on the stops where it adds value, typically the longer ones. Because the system already knows when the stop happened and which fault was active, it can suggest a likely reason and let the operator confirm or correct it. That means fewer inputs, better reasons and much less time spent logging.

Over time, the two sources also improve each other. Comparing operator reasons with machine fault codes for the same events shows where reason codes are too vague, where categories overlap and where certain faults are consistently misattributed.

What changes

When both stories are combined, the downtime picture becomes complete. The long stops still come with the context that explains them, and the short ones finally show up as specific, measurable losses tied to specific stations.

Maintenance can target the machine generating most of the short stops instead of chasing the general sense that the line is slow. OEE becomes easier to trust, because availability and performance losses both have causes attached. And operators spend their time fixing problems rather than documenting them.

Where to start

The simplest first step is a comparison. Take one line and a few weeks of data. Pull the machine states and stops from the PLC, and line them up against the operator-coded downtime log for the same period. Look at the number of stops, how their durations are distributed and which stations they come from.

The gap between the two is usually the first finding, and often the most useful one. It shows how much of the line’s loss has been sitting in plain sight inside the performance number, waiting for a cause.

‍