How to track downtime on older machines without a PLC

Half the advice about downtime tracking assumes every machine has a PLC, an HMI, and an Ethernet drop waiting for you to query it. On the floor of a real small shop, the worst offenders are usually the oldest machines: a 1998 press brake, a manual lathe, a packaging line that predates the people running it. They have no controller to poll, no state register to read, and no budget to retrofit. Yet they are exactly the machines you most need data on, because they stop the most.

The good news is that you do not need automatic data capture to run downtime improvement. You need honest, timestamped logging and a short reason-code list. This guide shows how to track downtime on older machines the manual way, what to capture, and how to decide later whether automatic capture is worth adding.

What about tracking downtime automatically on older machines?

You can. A machine with no controller still draws current, vibrates, and cycles, and each of those is a signal you can pick up without touching the original electrics:

Any of these can feed a small logger or a cloud service for a few hundred dollars per machine. It is a reasonable project, and later in this guide you will see exactly when it pays.

The catch is what the sensor cannot tell you. It knows the brake stopped at 10:42 for six minutes. It does not know whether that was a die change, a hydraulic fault, or the operator waiting on steel. Without a reason, you have a very accurate record of how much time you lost and no idea what to fix. That is why, on a legacy machine, the first month is better spent getting people to log stops with a reason than wiring a sensor that logs stops without one. Start with people, prove the process pays, then automate the machines where the payback is clear.

So the rule for older equipment: capture first, automate later, and only where the numbers justify it.

A current clamp on the motor feed, read by a small industrial I/O module or a hobby-grade microcontroller, tells you when the machine is running versus sitting idle.
A vibration sensor magnet-mounted to the frame does the same job on machines where current is hard to reach.
A cycle counter — a proximity switch or photo-eye on the ram, chuck, or conveyor — gives you parts per hour and, by inference, every gap between parts.

What "downtime" means when there is no controller to ask

Before logging anything, decide what counts as a stop. Without a PLC, nobody is drawing the line for you, so draw it yourself and write it down. A workable definition for a small shop:

Micro-stops — the 20-second jams that an operator clears without thinking — will not be captured by hand, and that is fine at this stage. If a machine's losses are dominated by micro-stops, that is itself a finding that justifies a sensor later. For most legacy machines, the money is in the stops long enough for a human to notice and log.

A stop is any period the machine is not making good parts when it was scheduled to run.
Only log stops longer than a threshold you choose. Pick a floor long enough that an operator can log the stop without losing the next part, and short enough that the losses you care about still get captured. Two minutes works for most shops; much past five and you start losing real events.
Separate planned stops (setup, changeover, scheduled maintenance, breaks) from unplanned stops (breakdown, jam, waiting on material). The two lead to completely different fixes.

The manual capture methods that actually survive a shift

Here are the approaches that work on machines with no electronics to tap, ranked roughly by accuracy.

Start/stop logging on a phone or tablet. The operator taps once when the machine goes down and once when it restarts. The software timestamps both, so duration is calculated from real clock time, not typed in from memory. This is the sweet spot: no new hardware, timestamp accuracy close to automatic capture, and a reason code attached at the moment the operator actually knows the cause. Decide up front whose device does the logging — the operator's phone, the lead's phone, or a tablet at the machine that each operator signs in to — so the log shows who was running it.

A tally sheet at the machine. A laminated card with the reason-code list and columns for start time, end time, and reason. Cheap and universal, but it depends on handwriting legibility and someone transcribing it, and durations get rounded hard. Use it only where a device genuinely cannot go.

A physical button or pull-cord wired to a simple counter. One rung above pure manual: a big button the operator hits when the line stops. It gives you accurate timing but no reason, so pair it with a quick reason selection. This is the natural bridge toward a sensor.

Reason-first, time-later is the trap to avoid. The worst method is a form filled out at end of shift from memory. The reasons are guesses and the durations are fiction. If you can only do one thing, make the stop get logged when it happens, even if the reason is just "Other, see note."

Keep the reason-code list short

Your reason codes are the whole value of the exercise, and the temptation is to make a 50-code list that covers every conceivable fault. Do not. Operators bury everything they cannot find quickly under "Other," and a 50-code list is slower to search than an eight-code list. Start with eight to twelve codes, grouped planned versus unplanned, and let the "Other" notes tell you which codes you are still missing.

A starter list for an older machine might be:

Make it a shop rule that "Other" always gets a note, and read those notes at month end. When a dozen of them say the same thing — "coolant pump tripped" — promote it to its own code. That is how a short list stays short and still gets more accurate every month. For a fuller taxonomy you can adapt, see machine downtime reason codes.

Planned: Setup / changeover, Scheduled maintenance, Break / no schedule
Unplanned: Mechanical breakdown, Jam / misfeed, Waiting on material, Waiting on operator, Quality stop / adjustment, Other (add a note)

A worked example: one old press brake, one month

Here is what the first month looks like on a single legacy press brake with no controller, logged start/stop from a tablet at the machine. The brake is scheduled for 160 run-hours in the month on a single 40-hour shift. Operators logged every stop over two minutes.

That is 47.7 hours of downtime against 160 scheduled hours, so the brake was running 70.2% of the time it was scheduled to. (This counts setup as a loss, which OEE does too, but it also counts scheduled maintenance against the machine — strict OEE availability would exclude that. The number is for comparing the brake against itself month to month, not for benchmarking.) Three things fall out that no one would have guessed:

Setup is 44% of all downtime, and it is planned. This brake runs small lots with frequent die changes. The fix is not a maintenance program — it is reducing changeover time. Knocking the average setup from 30 minutes down to 22 would return about 5.6 hours a month. That is nearly as much as eliminating every breakdown would (7.2 hours), and far easier to do, because changeover is a method problem you can fix with a stopwatch and a cart, not a reliability problem. If you have never timed a changeover, that is the obvious next project.

"Waiting on material" is a quarter of the loss, and it is not a machine problem at all. Twenty-eight stops where the brake was ready but the steel was not. That lives in scheduling and purchasing, not maintenance. Downtime tracking regularly drags a problem out of one department and sets it on another's desk — which is exactly why the log needs to be visible outside the maintenance office.

Jams are frequent but short. Thirty-one events for only 260 minutes. Each one is a minor annoyance, so nobody flagged it, but 31 interruptions a month is a signal. If the count keeps climbing, that is the machine where a simple sensor or a tooling fix would pay off — and now you have the data to justify it.

None of this needed a PLC. It needed 135 stops logged honestly from a tablet and one Pareto chart read in a Monday meeting.

When to add a sensor

After a clean month or two of manual data, you will know which machines deserve automation. The signals:

Even then, keep the reason codes human. A sensor can tell you the machine stopped at 10:42 for six minutes; only the operator can tell you it was a hydraulic fault. The best setup on an older line is often hybrid: automatic timing, human reason.

Micro-stops dominate. If an operator says "it jams constantly" but your log shows few events, the stops are too short and frequent to catch by hand. A cycle counter or a current clamp will reveal the real loss.
The machine is your top Pareto bar every month. Spend the retrofit money where it moves the biggest number, not evenly across the fleet.
Manual logging compliance is dropping. If operators on a high-stop machine stop logging because it is too busy, automate that one so the data keeps flowing.

Where HelpFab fits

HelpFab's downtime tracking is built for machines that cannot report for themselves. An operator opens a stop against a machine from a phone or tablet in a few taps, picks from your own configurable reason codes, adds a note if the cause needs explaining, and closes the stop when the line restarts — so durations come from real timestamps, not end-of-shift memory. The reports page builds Pareto charts and downtime-over-time charts for any date range, filtered to one machine or all of them and to planned or unplanned stops, with no controller, no integration, and no ERP behind it. The free plan covers a single app, so you can put logging on your worst old machine and prove the process before spending anything.

Start where this guide started: define what counts as a stop, keep the code list short, and get the stop logged when it happens. The sensor, if you ever need one, is the last decision — not the first. For the broader workflow once your data is flowing, see how to track machine downtime.

Latest articles

A fishbone diagram template for chronic downtime (with a worked example) — A ready-to-use 6M fishbone template for chronic manufacturing downtime, with a worked molding-line example that sorts causes and points at the real fix.
The 5 Whys template for chronic downtime (with a worked example) — A copyable 5 Whys root cause analysis template plus a worked stamping-line example that chases a recurring stop to its real cause and corrective action.
CMMS vs downtime tracking software — A CMMS manages assets and work orders; downtime tracking logs every production stop. Different jobs, not competitors — here is when a small shop needs each.
An andon system for a small shop, without the light tower — A low-cost andon for a small shop - what to signal, how to escalate, and how each call becomes a downtime log entry you can actually act on.
Track changeover time first, then SMED it down — Measure changeover time before you improve it - split internal from external work, see a worked die-change breakdown, and learn exactly what to log.
A production downtime report example, daily and weekly — A worked production downtime report for a CNC cell, the four numbers managers actually read, and a layout that turns lost minutes into action.
MTTR and MTBF: how to track them from your downtime log — Track MTTR and MTBF from your downtime and maintenance logs - the formulas, a worked quarter on one machine, and the mistakes that corrupt both numbers.
Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
OEE availability: how to calculate it from your downtime data — Calculate OEE availability from your downtime log, with a worked CNC example — plus the reclassification tricks that quietly inflate the number.
How to build a downtime Pareto analysis — Build a downtime Pareto step by step with a worked stamping-line example that finds the few causes driving most of your lost minutes.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.