Shift-end downtime logs are fiction with a signature.
Automatic stop detection to the second, reason capture in two taps, and the taxonomy design that decides whether the resulting data is usable at all.
Almost every plant already has a downtime record. It is written at the end of the shift, from memory, by someone who was busy for most of it, and it contains the events large enough to remember. It is not dishonest — it is simply incapable of containing the losses that matter most, which are the ones too small to recall and too frequent to ignore.
A downtime monitoring system replaces recollection with detection. The machine reports when it stopped and for how long; the operator supplies only the reason. That division of labour is the whole design, and getting it wrong is why most downtime systems are abandoned.
Detect, explain, act.
Automatic, to the second
Stops are identified from machine signals. Duration is exact, so a six-minute stop that happened forty times this month is visible for the first time — and that class of loss usually exceeds the breakdowns.
Two taps, at the machine
The operator selects a reason from a structured tree. Free text produces unanalysable mush; fifteen fields produce nothing at all, because nobody fills them.
A Pareto that builds itself
Top losses by machine, cell and plant, with trend lines that show whether a cause is growing or dying. The morning meeting stops being an argument about whose number is right.
The part that decides whether the data is usable.
A reason taxonomy that is too coarse tells you nothing — 'maintenance' as a category explains no more than the stop itself. Too fine and the operator cannot find the right entry in the time available, so they pick the first plausible one and your data becomes confidently wrong.
The workable structure is two levels: a small set of categories that map to who owns the fix — operational, material, quality, maintenance, management — with a handful of specific reasons under each, written in the words the floor already uses rather than the words the ERP uses. Ten to fifteen top-level reasons is usually right for a machining floor.
This is worth doing properly during the pilot rather than adopting a template, because a taxonomy that does not match how your plant actually stops will be worked around within a month.
Interlocking, and the honest trade-off.
Voluntary logging leaks. Busy shifts skip entries, and the Pareto quietly becomes a partial record that looks complete. Interlocking closes that gap: after a qualifying stop, the MachineWise device holds cycle-start until a reason is scanned or keyed, and releases it immediately afterwards.
It is not appropriate everywhere, and the trade-off should be stated. Interlocking adds a few seconds to a restart, and on a machine with many short legitimate stops that friction is real. The usual configuration applies it only to stops beyond a duration threshold, with a supervisor override that is itself logged. Safety circuits are never in the loop — the interlock gates cycle-start, not the machine's emergency stop or any safety chain.
Where it is used, reason coverage becomes a property of the system rather than a matter of discipline, which is the difference between a Pareto you can act on and one you have to caveat.
Beyond the Pareto.
Accurate stop durations make MTTR and MTBF computable per machine without a separate maintenance record, because the events and their lengths are already recorded. Recurrence analysis surfaces the chronic six-minute stop that everyone had stopped noticing. Crew and shift comparisons on identical machines separate a machine problem from a practice problem — a distinction that is otherwise a matter of opinion.
And because stops sit on the same timeline as counts and energy, a stop can be priced. The downtime cost calculator does that arithmetic with your machine-hour rate, which is usually the number that gets a corrective action approved.