When the Camera and the Operator Log Disagree: Which One Is Right?

Key takeaways

• Two lists, two kinds of stop. Paper keeps the long ones; the camera adds the short ones.
• Paper drifts: short stops go unwritten, long ones get rounded, and starved time gets booked as a fault.
• Reconcile on one timeline: the PLC (programmable logic controller) as the clock, the camera as the witness, the operator for the reason.
• OEE (overall equipment effectiveness) from real counts does not move. Performance usually falls, and the loss gets a name.

By the numbers

• Large plants suffer an average of 25 unplanned downtime incidents a month, down from 42 in 2019. (Siemens, 2024)
• Getting production running again after an unplanned stop takes 81 minutes on average, up from 49 minutes five years earlier. (Siemens, 2024)
• 69% of industrial plants have an unplanned outage on critical equipment at least once a month. (ABB, 2023)

When a camera shows 40 stops and the operator log shows 6, both are usually right about different stops. The log holds the long stops people remember. The camera also logs the short ones under the plant's threshold, which rarely reach paper.

Fabrico is a computer vision enabled Manufacturing Performance Platform. It is OEE and light MES (manufacturing execution system) software. It logs stops automatically, prices each loss in money and shows OEE live by line and shift.

The record is neither list on its own. It is one timeline: PLC times, camera clips and the reason the operator confirmed in one tap.

Why does the camera count so many more stops than the paper log?

A paper log is written by busy people, often at the end of the shift. It drifts in four ways.

• Short stops never reach paper. A 40 second jam is usually under the plant's threshold for writing a stop down. No standard sets that threshold; each plant picks its own.
• Stops get rounded and rebuilt from memory. A 7 minute stop becomes "10 min" at shift end.
• Stops get merged or split. Eight short jams become one line, "infeed jams, 20 min". One long stop with a failed restart becomes two.
• Starved or blocked time gets booked as a fault. A wrapper waiting for product is starved; one that cannot pass packs on is blocked. Paper often says "wrapper down" for both.

Short stops hide inside performance as "slow running" until something counts them. Our guide to finding and fixing micro stops covers what to do next. Stops logged with no reason are a separate problem: see why unclassified downtime hides real losses.

Can the camera be wrong and the log right?

Yes. A camera sees one field of view in one range of light.

• False alarms. A person stands in front of the outfeed, or the light changes, and the camera logs a stop that did not happen.
• Stops outside its view. A fault inside the machine may not show until product stops where the camera looks.
• Planned time. A break looks like a stop to a camera. The shift plan says it does not count.

So the raw camera count is not the record either: each event needs the operator's one-tap check.

How do you put the camera and the log on one timeline?

1. Start from the PLC times, or the camera's time stamps at a manual table, and lay the camera events and clips on top.
2. Match each paper entry to the events at that time. Split merged entries and join split ones.
3. Apply your threshold. Longer stops go to availability, shorter ones to performance as minor stops.
4. Send starved and blocked time to the machine upstream or downstream that caused it.
5. Ask the operator to confirm each reason in one tap, with the clip at hand.

For the setup, see how to connect line cameras to MES downtime codes. For the screen, see an OEE dashboard with video context.

Who decides the stop reason, the camera or the operator?

The operator. The camera may suggest a likely reason, such as a biscuit on its side at the infeed. The operator confirms or changes it in one tap while the stop is fresh, not on a form at shift end.

The clip works for the operator. The first time it shows the wrapper stopped because product arrived late, not because someone was slow, the operator starts trusting the system.

That trust needs one rule: the camera watches the process, not the person. No faces, no names, no scores per operator.

In Germany, section 87(1) no. 6 BetrVG gives the works council a say over technical equipment that can monitor behaviour or performance. Intent does not matter. This is not legal advice: check with your data protection officer and, in Germany, your works council.

What does a worked example of a disagreeing shift show?

Sample line (illustrative numbers, not a customer). A biscuit line ends at a flow wrapper, the bottleneck, rated at 100 packs a minute. Planned time is 480 minutes. Stops under 2 minutes are minor stops. The counter shows 37,500 packs made and 36,750 good.

Method note: Sample line, illustrative numbers, not a customer. Every result above comes from the inputs listed and the formula shown with it, so you can repeat the calculation with your own line's numbers.

The totals are close: 95 minutes on paper, 94 confirmed. The split is not. Five confirmed stops run over 2 minutes, 64 minutes in all. The other 33 are minor stops, 30 minutes.

• Paper: run time = 480 minus 95 = 385 minutes. Availability = 385 / 480 = 80.2%. The 37,500 packs need 375 minutes at full speed, so performance = 375 / 385 = 97.4%.
• Confirmed: run time = 480 minus 64 = 416 minutes. Availability = 416 / 480 = 86.7%. Performance = 375 / 416 = 90.1%.
• Quality = 36,750 / 37,500 = 98.0% in both.
• OEE = 80.2% x 97.4% x 98.0% = 76.6% on paper, and 86.7% x 90.1% x 98.0% = 76.6% confirmed. Check: 36,750 good packs need 367.5 minutes, and 367.5 / 480 = 76.6%.

Same OEE, different story. Availability loss fell from 95 to 64 minutes. Performance loss rose from 10 to 41 minutes, and 30 of those are now 33 named short stops. At a sample margin of $0.10 a pack (€0.10 in a euro plant), the short stops cost 3,000 packs, or $300 a shift.

What happens to your OEE when you switch to the camera count?

If OEE comes from real counts, the total stays the same. OEE equals good count times ideal cycle time, divided by planned time, and none of those change. The split does.

• Performance usually drops, as short stops land there as minor stops.
• Availability often rises when paper rounded long stops up. It falls if the camera finds long stops nobody wrote down.
• The loss gets a name. "Slow running" becomes counted stops with clips and confirmed reasons.

Expect the first reports to look worse on performance. That is the measurement getting honest, not the line getting slower.

Next, read how computer vision helps cut micro stops. Fabrico starts with a pilot on one line. See how a stop gets its clip and confirmed reason on the computer vision OEE feature page. There is no free plan and there are no tiers: each plant gets a quote.

Proof from a named plant: Ficosota raised factory-wide OEE from 53.1% to 59.6%, with good output up 23.2% a month from June to September 2026. Read the Ficosota case.

Toyota calls jidoka "automation with a human touch": the machine stops on a problem, and a person decides what happens next. (Toyota, Toyota Production System)

Frequently asked questions

Which is right, the camera or the operator log?

Neither on its own. The camera usually counts more stops because it logs short ones that never reach paper, but it can raise false alarms. The log holds the reasons people remember. The record is the confirmed stops on one timeline, with PLC times and camera clips.

Why do operators write fewer stops than the camera shows?

A stop cleared in under a minute is rarely worth writing down. The log is often filled in at shift end from memory, so stops get rounded, merged or booked to the wrong machine. That is not bad work by operators: paper cannot keep up with short stops.

Will our OEE go down when we use camera data?

Not if your OEE comes from real counts: the total stays the same, but the split changes. Performance usually drops as short stops move into it. Availability often rises as rounded stops shrink to their real length. Tell the team before the first report.

What do we do with log stops the camera did not see?

Check each one. Either the camera missed it, because the view was blocked or the fault sat outside the frame. Or it was not a stop, such as a planned break. Fix the view for the first kind and the log's coding for the second.