In short: Unclassified downtime is stop time with no reason attached, or with a vague one like "other". It grows when the reason list is long, people are asked too late, and nobody reviews the gaps.
Unclassified downtime is the time a line was not producing, but nobody has said why.
You will also hear it called unexplained downtime, unknown downtime reason, or downtime with no reason code.
The machine data shows a stop. The reason field is empty, or it says "other", "unknown" or "misc".
It is not the same as unplanned downtime. A stop can be clearly unplanned and still have no reason yet.
The time still counts as lost time in OEE availability. What is missing is the explanation.
Usually not because people do not care. The system makes the honest answer hard.
A big grey bucket does two kinds of damage.
First, it makes the ranking wrong. Your Pareto of downtime puts "no reason" first, and you cannot act on that.
Second, it splits real causes. Three real reasons can each look small while together they are your top loss.
In the Hansen method for OEE, every minute of scheduled time belongs to a named category, and OEE plus all the losses add up to 100%.
Hansen also says not to use "other" or "miscellaneous" as a category.
A catch-all defeats the method. Unclassified time is fine as a short waiting room before the review. It is not fine as a place where time lives.
Example data, round numbers, one line, one shift.
That is 8.3% of scheduled time, and about 42% of all stop time.
Availability is 80% before and after the review. Only the explanation changes.
Now look at the Pareto before and after the review.
Before the review, the team would have started a project on "no reason".
After it, they know the line loses 59 minutes a shift to a jam and to waiting for material.
People answer better with a short list than with a long one.
There is no standard number. Some downtime software vendors give a target, but treat it as a rule of thumb.
A simple test: give three operators the same five stops. If they pick different reasons, merge or rename.
A few rules that work:
The best moment to ask is when the stop happens or right after the line restarts.
Make it two taps. The operator picks the machine and then the reason.
Put the most used reasons one tap away. If your machines send alarm codes, map the clear ones to reasons so people only judge the unclear stops.
Add a short catch-up before each break and at the end of the shift. It is easier than a long one later.
Not every pause needs a reason. Asking about every 20-second jam trains people to tap anything.
Pick a threshold that fits your line. Stops shorter than it are not asked about, but they are still counted.
Count them as lost speed. Do not drop them. Many small stops add up, and our guide on micro-stops shows how to find them.
This step does the most. A short slot in the morning meeting is enough.
When the review becomes routine, the shift habit changes. People see their notes read, so they write them.
Some stops have no witness. A camera over the line can show what happened, such as no material, a spill, or a broken part.
The useful way to use it: the camera suggests the reason and a person confirms it. The video makes the confirmation fast and removes the guessing.
The camera watches the process, not the people. That keeps the review about the line.
Track the unclassified share of stop time per line, per week.
There is no standard target. Take your current share as the baseline and push it down step by step. Treat any vendor target as a rule of thumb.
A rising share is an early warning. The list has grown, the capture has slowed down, or the review has stopped.
| Area | Weak | Good |
|---|---|---|
| Reason list | Long, overlapping | Short, clear, per machine |
| When it is captured | End of shift | At the line, same shift |
| Short stops | Ignored or all asked | Threshold set, still counted |
| Unclassified time | Piles up for weeks | Reviewed next morning |
| "Other" | In the top three | Avoided, or small and split when it grows |
| Unseen stops | Guessed | Checked with evidence |
Fabrico is a light MES in the cloud. It takes OEE and downtime from machine data (PLC, IoT sensor or camera) and adds the stop reason from the people on the line.
If you also use the maintenance module, a stop reason can open a task automatically. That is a side benefit, not the point.
Fabrico does not pick a reason without a person confirming it. It shows the unexplained time so your team can explain it.
Request a demo or Contact us to see unclassified time on a live line.
No. Unplanned says the stop was not in the plan. Unclassified says nobody has recorded why.
Both labels can sit on one stop. A good downtime tracking system shows both.
There is no standard number. Start with the stops you really see, and keep the list short enough that an operator finds the right reason fast.
Show each machine only its own reasons. Use the review to learn which reasons are never used and which are missing.
No. Set a threshold and count the short stops automatically. Then use a Pareto of downtime to see if the short stops add up to a top loss.
As lost time, in availability. Do not exclude it to make OEE look better. The aim is to give it a reason, not to hide it.
Once a stop has a reason, your own rules apply. For example, a mandatory break can be set to leave the availability base.
Partly. A machine alarm code can map to a clear reason. A camera can suggest one. For human causes, such as no operator, a person should confirm.
That depends on your margin and your line. Our free field guide, why lines stop, walks through how to price a stopped hour so that you can rank stops in money, not minutes.
Ready to see where your unexplained time goes? Request a demo or Contact us.
Login
Blog