Tracking Machine Downtime Without an IoT Budget

The pitch you're getting right now

Someone has probably shown you a dashboard. Machines lit up green and red, uptime percentages ticking in real time, a sensor that clips onto the machine and "just works" without touching the PLC. The number quoted is usually per machine, per month, and it sounds reasonable until you multiply it by every machine on the floor.

Here's the question nobody selling that dashboard wants you to ask first: do you already know why your machines stop?

Not roughly. Not "operators say it's mostly breakdowns." Precisely, by category, with numbers you'd defend in front of your bank. Most manufacturers we talk to don't have this, and no sensor fixes that gap. A sensor tells you a machine stopped at 11:42 AM for 34 minutes. It does not tell you whether that stoppage was a bearing failure, a missing die, an operator on a tea break, or the plant head waiting on a decision that could have been made an hour earlier. That reason still has to come from a person, written down, at the time it happened.

This is the sequencing most vendors skip, because the sensor is the sale, not the fix.

Why does IoT get pitched before downtime logging is fixed?

Because a hardware retrofit is a clean, billable line item, and a logging habit is not something anyone can invoice for.

A sensor company's incentive is to sell sensors. Their demo works beautifully because it's running on a machine in their own facility, with clean data and no politics. What they don't show you is what happens when your fitter reports a stoppage as "machine problem" for the fortieth time that month, and nobody in your plant has agreed what that phrase actually means. IoT gives you a precise timestamp for an imprecise cause. That's not visibility. That's a more expensive version of the confusion you already have.

The correct order is: fix what counts as a reason first, log it by hand until the categories are stable, then decide where sensors earn their cost. Guidewheel's own buyer's guide for plants without a PLC makes a similar point from the vendor side: automatic capture only pays off once you know what you're trying to capture.

What should you track manually before spending on sensors?

Three things, on every stoppage, written down at the time it happens: what stopped, for how long, and why, using a reason from a fixed list your team already agreed on.

This can run on a paper register at the machine, a shared spreadsheet, or a WhatsApp message to a supervisor if your floor culture already uses that. The tool doesn't matter yet. What matters is that the same three fields get captured every single time, by every shift, without exception. A downtime log with gaps is worse than no log, because it lets you believe you have data when you have a sample.

Do not automate a bad process. If your current practice is an operator scribbling "stopped" in a diary at the end of the shift, digitising that diary with a sensor just gives you a faster, more expensive version of the same guesswork.

What root-cause categories actually matter?

A short, fixed list beats a detailed one. Six to eight categories, agreed once, used consistently, will tell you more in six weeks than a sensor feed you can't interpret.

Most plants we've seen do this well settle on something close to the table below. The categories matter less than the discipline of using the same ones every time, so a stoppage in week one and a stoppage in week six can be compared honestly.

Category	What it actually means	Who decides the fix
Breakdown	Machine fails mechanically or electrically mid-run	Maintenance head
Changeover	Time lost switching jobs, dies or settings	Shift supervisor
Material wait	Machine idle because input material hasn't arrived	Stores / planning
No operator	Machine capable of running, nobody assigned to it	Plant head
Quality hold	Stopped to check or rework output	Quality in-charge
Power / utility	External failure: power cut, compressor down, etc.	Plant head
Planned maintenance	Scheduled stop, not a loss in the strict sense	Maintenance head

The column that matters most is the last one. A downtime log that doesn't name who owns the fix for each category just becomes a record of complaints. Naming the decision-maker against each category turns the same data into a list of actions someone is accountable for closing.

How do you build logging discipline on the shop floor?

Start with one shift, one week, and a supervisor who checks the log every evening, not once a month.

The biggest failure mode isn't the format of the log. It's that nobody reviews it until someone needs a report, by which point the categories have drifted, entries are missing, and half the "reasons" are useless phrases like "issue" or "delay." A supervisor spending ten minutes at the end of each shift, reading the day's entries and pushing back on vague ones, does more for data quality than any software feature.

Once a shift is logging cleanly for two to three weeks, extend it to the next shift, then the next machine line. By week six, you should have enough entries to run a simple Pareto: which two or three categories account for most of the lost hours. That answer, not a sensor feed, is what tells you where to spend money next.

Mikromes' step-by-step guide on moving off spreadsheets is a useful read once you're at this stage and the spreadsheet itself has become the bottleneck, not the discipline behind it.

When does IoT retrofit actually make sense?

Once your manual log tells you where operators can't or won't capture the real cause fast enough for it to matter, and where the value of automatic capture is bigger than the cost of the sensor.

There are genuine cases where sensors earn their place. A high-speed line where a stoppage of ninety seconds happens forty times a shift and no operator can log each one accurately. A night shift with weak supervision where paper logs go missing. A machine where the actual failure mode (a slow speed creep, say) never shows up as a full stop and so never gets logged by hand at all. In these cases, a retrofit that clips onto the machine's power draw or output pulse, without touching the PLC, can genuinely close a gap manual logging can't. Guidewheel's technical piece on automatic tracking on older machines and this walkthrough on legacy OEE monitoring with open tools are both useful once you're at that decision point, not before it.

The test is simple: can you point to specific weeks of manual data that show a gap sensors would close? If yes, spend the money on the machines where that gap is real. If the answer is "we're not sure, but it looks impressive," you're buying a dashboard, not solving downtime.

What does this look like once it's running properly?

A plant head who can open one sheet on a Monday morning and say, in one sentence, why last week's output was short, and who is fixing it. Not a dashboard someone has to be trained to read. Not a report that arrives on the 5th of the month for problems from the 1st.

That one sheet is also the foundation for anything you build later, whether that's a proper MES, a simple digitised log replacing the paper register, or a targeted sensor rollout on the two machines that actually need one. Software built on top of clean categories and disciplined logging works. Software built to paper over a process nobody agreed on just moves the confusion onto a screen.

This is the same principle behind most of what we do at ThetaSol before writing a line of code: we understand how your business actually works first, then we design the system. Downtime tracking is one of the clearest examples of why that order matters, because the tempting shortcut, buying sensors before fixing the logging habit, is expensive and doesn't fix the underlying problem.

If you want a wider view of how this fits with the rest of shop floor visibility, planning and follow-ups, the Manufacturing Operations hub is the place to start. And if you're at the point of deciding what to build once your logging discipline is solid, our digital transformation service page covers how we sequence that work.

What to do this week

Pick one shift on one line. Give the supervisor a fixed list of seven reason categories, a simple register, and one instruction: every stoppage gets logged with a duration and a category, no exceptions, checked every evening. Run it for two weeks before you take a single vendor call about sensors.