What should you look for in a downtime tracking system?

What actually decides whether a downtime system works?

One number, and it is not on any vendor’s website: the share of your stopped time that ends up with no reason attached to it. A system with a beautiful Pareto chart over forty percent unlabelled downtime is a system that has told you nothing, at length.

Everything below is a way of getting at that number before you buy. How a stop gets detected, who codes it and when, what happens when nobody does, and how a wrong reason gets fixed. The reporting matters less than any of it, because reporting is the easy part and every product on your shortlist can do it.

How does a stop get detected at all?

Before anybody codes anything, something has to notice the machine stopped. That happens in one of a few ways: a device already counting on the line, a signal read off the machine control, a sensor installed for the purpose, or a person pressing a button. They give you different accuracy and different install costs, and only the last one is free.

Resolution matters as much as the mechanism. A system that records production in fifteen-minute buckets cannot tell you about a four-minute stop, no matter what its dashboard looks like.

Ask them: for my machines, what detects a stop, and what is the shortest stop that appears as its own event rather than being averaged into a slow period?

A weak answer sounds like: "we capture downtime automatically" with no mention of what is doing the capturing. Ask what happens on the line that has nothing on it today.

Who assigns the reason, where, and when?

A reason chosen at the machine while the stop is happening is usually right. A reason chosen by a supervisor the next morning from a list of yesterday’s stops is usually a guess with better handwriting. Most plants end up doing both, and the design question is whether the software supports that or pretends the first one always happens.

Watch where the entry happens. A screen at the machine, a shared tablet at the end of the aisle, and a desktop in an office are three completely different adoption stories.

Ask them: show me an operator coding a stop at the machine, and then show me a supervisor coding yesterday’s uncoded stops. How does the second one know what happened?

A weak answer sounds like: only ever demonstrating the supervisor view. That is the easy screen, and it is not where the data comes from.

What happens to downtime nobody labels?

The core criterion. Something always goes uncoded: the stop during a changeover nobody thought counted, the twenty minutes while the only operator was at lunch, the night shift.

What separates products is whether that is designed for. Prompting for a missing reason at the machine rather than waiting to be visited. A report a supervisor can work through. A rule that fires when a stop has been open with no reason for long enough. A requirement that long stops carry a written explanation rather than a code, because "Equipment Failure" for six hours explains nothing.

Ask them: show me the report of unlabelled downtime for last month. How does the system chase it, and can it require an explanation on stops over a threshold I set?

A weak answer sounds like: "operators are required to enter a reason". Required by what, and what happens when they do not? If the answer is a policy rather than a mechanism, you are buying a policy.

Who owns the reason list, and how does it change?

Your reason list is the vocabulary the whole system thinks in, and it is wrong on day one at every plant. New failure modes appear, two reasons turn out to mean the same thing, and the list written in a conference room does not survive contact with the floor.

So the question is not whether the list is configurable, which it always is. It is who can change it, how quickly, and what happens to last quarter’s reports when they do.

Ask them: who at my site can add a reason code without contacting you, and what happens to historical reports when a code is renamed or retired?

A weak answer sounds like: "we configure that during implementation", offered as the whole answer. Implementation happens once; the list changes forever.

Can a stop be corrected, and can you see who corrected it?

Recorded downtime is wrong sometimes. One recorded stop was really a ten-minute jam followed by fifty minutes waiting for maintenance, and those belong in different buckets. Somebody picked the wrong reason. A stop was planned and nobody said so.

Both extremes fail. A system that will not let anybody fix anything accumulates known-wrong data until people stop citing it. A system where anybody can silently rewrite history cannot be used to settle an argument, which is most of what this data is for.

Ask them: split this recorded stop into two events with different reasons, in front of me. Then show me where that edit is recorded and who can see it.

A weak answer sounds like: "you can edit anything". The follow-up is always the audit trail, and if it does not exist, that is a finding.

What about micro-stops and slow running?

The losses nobody reports are frequently the largest. A jam cleared in twenty seconds happens forty times a shift and nobody enters a thing. A line running at eighty percent of rate all week loses more than the failure everybody remembers.

Ask how the product treats them, because the honest answers vary. Some record short stops separately, some fold everything under a threshold into performance loss, and the threshold is sometimes not adjustable.

Ask them: what is your short-stop threshold, can I change it, and where do slow cycles show up separately from stops?

A weak answer sounds like: a demo that only shows long failures. Every product looks good on a two-hour breakdown.

What does the operator actually have to do, in seconds?

Count it rather than discussing it. From the machine stopping to the reason being recorded: how many taps, is there a login, does it work with gloves on, and does the screen survive being touched by somebody in a hurry.

This is not a usability nicety. It is the mechanism that produces every number the system will ever show you, and the difference between two taps and a form is the difference between real reasons and a default picked to make the prompt go away.

Ask them: put the demo on a tablet, stand up, and code a stop the way an operator would. How many seconds?

A weak answer sounds like: "the interface is very intuitive", from somebody sitting down with a mouse.

Do the comments get reported, or just stored?

The free-text an operator types is where the reason nobody coded correctly actually lives. "Third time this week, waiting on the crane again" is not any reason code on your list, and it is the sentence that would change what you do.

Most systems will store that text. Fewer will let you report on it: group it, count it, put it next to the reason codes it was filed under, and find the pattern.

Ask them: show me a report of what operators typed last month, grouped by something useful. Can I search it?

A weak answer sounds like: a comment field that can only be read one event at a time. That is a notepad attached to a database.

Who gets told while it is still happening?

Downtime tracking that only produces reports makes yesterday clearer without changing today. The alert worth having on day one is unglamorous: a line down longer than a set number of minutes, or a stop sitting open with no reason on it, reaching a person who is not looking at a screen.

Ask how it is delivered, because the channel decides whether it works at your site: an in-app banner, an email through your own relay, a text message, or a post into a chat tool. They differ in what has to leave your network, which is a policy question as much as a technical one.

Ask them: what triggers can I write without your help, and for each delivery channel, what data leaves my network to make it work?

A weak answer sounds like: "real-time notifications" as a feature bullet, with no detail about the trigger conditions or the delivery path.

What happens to a loss once you have found it?

Finding the top loss is the easy half. What changes a plant is somebody owning a countermeasure, a date, and a check months later that the gain held. Some products carry that workflow; most hand you a chart and leave the rest in a spreadsheet.

Ask them: from this downtime Pareto, create an action with an owner and a due date, and show me how I would know in three months whether it worked.

A weak answer sounds like: an export button. That is a real answer if you already run improvement work somewhere else, and it is not the same as the product doing it.

Where do we fit against these criteria?

One criterion first where we are not the best answer available.

If your floor will not code reasons, buy something that does not ask. Products exist that capture downtime with no operator involvement at all - Datanomix markets "No Operator Input" as the point of the product - and for a shop where nobody is going to touch a screen, a truthful thin number beats a rich wrong one. Our system asks the floor for reasons, jobs and labour, and that time is a real cost. The sourced version of that trade-off is on our Datanomix comparison.

Against the rest:

• Tracked countermeasures. Continuous Improvement turns agreed fixes into tracked work with an owner, a status, and statistical proof the change held.
• Detection. On a Vorne XL line the board is already timing states and counting parts, so nothing new gets installed to detect a stop. Lines with no board are covered by a manual station that records the same data.
• Coding, and not coding. Work Tracker puts reason entry at the machine with a required prompt for missing reasons, and carries an extended-downtime workflow for the long stops that need a written explanation rather than a code. Reason codes, states and reject categories are pushed back to the board, so the wall and the report agree.
• Correcting. A recorded stop can be split at a point in time into two reasons, which is the case that comes up most: a short fault followed by a long wait.
• Comments. What operators typed is reportable rather than only viewable, and it is usually where the reason nobody coded correctly turns up.
• Alerting. Rules combine metrics, process states, your own reason codes, a threshold and a duration, so "down more than fifteen minutes with no reason entered" is one rule. What crosses your network boundary on each channel is set out honestly on the alerting page.
• Reporting. Downtime analysis, reason codes and top losses are standard in OEE Explorer, which installs on premises or in the cloud. On an in-plant install the underlying production records sit on a database on your own server.

If the evaluation is broader than downtime, the general OEE software guide covers deployment, exit terms and cost structure. If the boards are already on the wall, choosing software for Vorne XL is the one written for that. Product-by-product comparisons with sources and access dates are on the comparison hub, and the alternatives pages for MachineMetrics, Evocon and Shoplogix list the field around whichever product you were sent to look at.