Downtime Tracking: Clipboards, Spreadsheets, and What Comes After

Downtime tracking is the practice of recording when each machine stopped, for how long, and why. Every shop does it somewhere on a spectrum: clipboard sheets filled in at shift end, spreadsheets typed up from those sheets, or automated systems that detect stops from sensors and ask operators only for the reason. The clipboard catches maybe half of real downtime; automated detection catches essentially all of it. That gap, the invisible half, is usually where the money is.

Ask a plant manager how much downtime a machine had last month and you'll get a number. Ask how they know and the trail usually ends at a sheet of paper with entries like "down ~45 min, maintenance." The machine's actual log, if it could speak, would tell a different story: nine stops, not one, and the long stop was 71 minutes, and four of the short ones were waiting on material, which isn't a maintenance problem at all.

Why Downtime Tracking Beats Almost Any Other Improvement Project

Downtime is the largest and most fixable loss in most small plants, and it's the availability term in the OEE calculation, typically the biggest of the three factors' losses. But the case for tracking it well rests on one observation: downtime causes cluster. It's rarely twenty different problems. It's usually three problems happening over and over: a changeover that takes 40 minutes and could take 15, a material delivery loop that starves the same machine every morning, a fault that maintenance resets in ninety seconds without ever finding the cause.

You can't see the clusters without timestamps and reasons. With them, the top of the Pareto chart practically schedules your next month of improvement work for you. A shop that eliminates its number one downtime cause often recovers 3 to 5 percent of capacity without buying anything.

The Clipboard Stage (An Honest Defense)

Let's not sneer at the clipboard. A paper log at the machine costs nothing, needs no IT, and starts producing data today. For a shop that has never tracked downtime at all, two weeks of clipboard data is a revelation, and we'd rather see a used clipboard than an unused software license.

Its failures are predictable, though, and worth naming. Entries get written at the end of the shift, from memory, so durations are rounded and short stops vanish entirely; a stop under five minutes has roughly zero chance of making it to paper, and a machine can bleed an hour a shift in stops under five minutes. Reasons are freeform, so the same problem appears as "jam," "jammed," "feeder," and "the usual," and no one can total it. And someone has to type it all up, which means someone doesn't, and by March the binder is decoration.

The clipboard's real product isn't data. It's the habit of noticing stops. Bank that habit and move on within a quarter.

Spreadsheets: The Awkward, Necessary Middle

The spreadsheet stage adds arithmetic and dropdowns to the clipboard, and it's a genuine upgrade. Standardized reason codes in a validation list, durations that sum, pivot tables that produce your first real Pareto chart. Many shops learn more from their first month of spreadsheet Paretos than from any consultant.

The ceiling arrives on schedule, though. Data entry lags reality by hours or days, so the Monday meeting reviews last Tuesday's problems. The person who owns the sheet becomes a single point of failure (watch what happens to the data when they take vacation). Timestamps are still human-remembered fictions. And the micro-stops are still invisible, because no spreadsheet fixes a collection problem; it only formats one.

The tell that you've outgrown the stage: someone starts asking questions the data can't answer. "Is it always after changeovers?" "Is night shift really worse or does it just log more honestly?" Those are timestamp questions, and humans don't produce trustworthy timestamps.

What Comes After Spreadsheets?

Automated stop detection plus human reason codes. That division of labor is the entire design, and every good downtime system is a variation on it.

Machines are excellent at knowing when they stopped. A current transformer, a cycle sensor with a timeout, or a run bit read from the PLC over Modbus TCP or Ethernet/IP gives you every stop, with start and end timestamps accurate to the second, forever, with no memory or diplomacy involved. Our guide to getting production data out of old machines covers the retrofit options; even a stack light tap is enough for stop detection.

Humans are the only ones who know why. So when a stop ends (or better, while it's running), a tablet at the machine shows the stop and asks for a reason with big, tappable buttons. One tap, two seconds, done. Some systems auto-classify what they can (a fault code from the PLC needs no human input; a stop during scheduled break gets labeled automatically) so operators are only asked about genuinely ambiguous stops.

The payoff is immediate and a little unsettling. Total downtime typically measures 1.5 to 2 times what the clipboard reported, with the difference almost entirely in short stops. The Pareto chart changes shape within a month, and at least one long-held theory about "the problem machine" usually dies on contact with the timestamps.

Designing Reason Codes People Will Actually Use

This is the make-or-break detail, and it's a human factors problem, not a technical one.

Keep the list short: eight to twelve codes at the top level, not forty. Operators facing a wall of options tap the first plausible one, and your data becomes a measure of button position. Structure codes by what the fix would be, not by org chart: "waiting on material," "changeover," "tooling," "machine fault," "quality hold," "no operator" each point at a different owner. Always include a real "other" with a free-text field, then review what lands in it monthly; recurring write-ins are your next official codes.

Two rules from hard experience. First, never make the reason screen a blame instrument. The moment codes feed a discipline conversation, the data politely dies; every stop becomes "machine fault." Second, close the loop visibly. When operators see the "waiting on material" total trigger an actual change to the forklift route, tap compliance stops being a compliance problem.

What Automating Downtime Tracking Typically Costs

Sensing hardware runs the usual retrofit range: typically $500 to $1,500 per machine where there's no accessible controller, or a $200 to $700 gateway where there is one. Floor tablets in rugged mounts add $200 to $600 per station. On software, subscription downtime/monitoring platforms often run $50 to $150 per machine per month; a custom stack (broker, database, purpose-built stop screens) is a bigger up-front build, typically tens of thousands with engineering, and makes sense as machine counts grow or when the stop workflow needs to match how your floor actually works rather than how a vendor imagined it. The interface design matters more than the platform brand; a clumsy reason screen fails identically at every price point, which is why we treat the operator-facing screens as serious software engineering rather than an afterthought.

Payback tends to be quick because the target is so large. If a shop runs 80 hours a week of machine time at even $75 per hour of contribution, recovering 3 percent of it is roughly $9,000 a year per machine. The math rarely needs a sharpened pencil.

FAQ

How much downtime goes unrecorded with manual tracking?

Commonly 30 to 50 percent, concentrated almost entirely in stops under ten minutes. Long breakdowns get logged everywhere; micro-stops get logged nowhere. Since micro-stops often share one root cause repeated dozens of times a day, the unrecorded half is frequently the more fixable half.

Should downtime reasons be entered by operators or supervisors?

Operators, at the machine, as close to the stop as possible. Supervisor-entered reasons are secondhand and late, and end-of-shift entry reintroduces every memory problem the clipboard had. The supervisor's role is reviewing the data and acting on it, not transcribing it.

What counts as downtime versus planned time?

Pick a definition and freeze it: anything scheduled before the shift (planned maintenance, planned changeovers, breaks) is planned time; anything that surprised you is downtime. The specific line matters less than its stability, because a drifting definition lets the numbers improve while the plant doesn't.

Can I automate downtime tracking on machines with no PLC?

Yes, and it's routine. A split-core current transformer on the motor feed or a cycle sensor with a timeout rule detects stops on machines with zero electronics. Stop detection is actually the easiest monitoring problem; you only need to know running versus not-running, and almost any machine leaks that signal somewhere.

If your downtime data lives on a clipboard or in a spreadsheet that one heroic person maintains, you're one modest project away from seeing your floor clearly. Willowark's industrial automation team builds downtime systems that operators tolerate and managers trust. Tell us about your worst machine and we'll tell you what it would take.