What Is Downtime Analysis?
Downtime analysis is the process of recording when production stops, why it stopped, and how much output was lost. It turns “the line was down” into useful facts your team can act on. For production managers, it is the link between shop floor reality and the numbers that matter: OEE, downtime minutes, micro-stops, and planned vs actual output.
A good downtime analysis section should help you see:
When stops happen: Which shift, machine, order, or product lost time.
Why production stopped: The reason operators choose while the event is still fresh.
How much output was lost: The gap between what you planned to make and what the line actually produced.
Where to improve first: The recurring losses that reduce availability, slow performance, or create quality problems.
Good downtime analysis gives production, maintenance, and planning a shared view of what went wrong, so they fix the right problem faster.
Want to see what downtime tracking looks like in practice? Explore the free demo with sample production data. No financial commitment needed.
Why Most Reason-Code Lists Fail
Reason-code lists usually fail for two reasons: they are hard for operators to use during a real stop, and they let planned downtime hide real production loss. A useful list makes the right reason obvious, but it also makes the planned vs. unplanned choice strict enough that availability cannot be made to look better than it is.
A fallback reason hides a broken setup. GlobalReader does not need an “Other” option by default. If operators cannot find the right interruption reason, the company should fix the initial categorisation or review the process behind the stop. If operators use “Other” too often, the list is missing common reasons or the labels are unclear.
Planned interruptions get used as a hiding place. If tool changes, quick cleanups, product changes, or small pauses are marked as planned by default, availability looks better while the factory keeps losing time.
End-of-shift guessing weakens the data. When reasons are logged hours later, people rely on memory instead of what actually happened at the machine.
Small stops get skipped. If a list takes too long to search, short stops and micro-stops disappear from the record. Repeated micro-stops can create a 5-15% hidden loss across a shift.
Long lists create friction. Use about 5 high-level groups, with 3 to 5 reasons inside each group, so operators can choose quickly without scrolling through every rare case.
GlobalReader tip: Do not give operators an option to choose “Other” as an interruption reason. Start with clear default interruption reason groups, let operators add comments for detail, and review the list when the same comment keeps repeating.
A good reason-code list fits shop floor work. It should help operators explain what happened, not turn downtime tracking into extra paperwork.
A Starter Reason-Code Taxonomy: 8–12 Codes Max
A good downtime reason-code list is short enough for operators to use during a stop, but specific enough for managers to see patterns across shifts and lines. Start with 8 to 12 codes so operators get fast choices under pressure and leaders get cleaner data than a long list filled with guesses and “Other.” The bigger rule is this: most work-process stops should be treated as unplanned unless the company has agreed on a fixed planned window.
GlobalReader’s downtime tracking software starts with clear default clusters, then each company can add, remove, or rename reasons later. For each interruption reason, define what counts as planned before launch, not after a bad availability number appears.
A typical default setup looks like this:
| Interruption group | Default interruption reasons |
|---|---|
| Setup | Batch change or product switchoverPreparationTool changeover |
| Failure | BlockageMechanical breakdownPower failure |
| Maintenance | CalibrationMachine checkupPart replacement |
| Breaks | LunchSmall break |
| Material | Material defectMissing materialOverstock blocking work areas |
A practical rule: lunch breaks, legally required rest breaks, and scheduled planned maintenance are planned. Tool changes, cleanups, product changes, meetings, and waiting time are unplanned unless they are scheduled, agreed, and measured as part of the production plan.
Wood and Furniture Lines
Wood and furniture lines often lose time around tooling, sanding, glue, press work, materials, and changeovers. Keep the first version practical and close to the words operators already use.
Be strict with planned time here. A saw blade change inside an agreed setup window is different from stopping twice per shift because the blade was not checked early enough.
Metal and Machining
Metal and machining teams usually need interruption reasons that separate setup, failures, maintenance, breaks, and material issues. This helps supervisors see whether lost time is coming from preparation work or from production interruptions.
For example, a planned setup window is one thing. Repeated stops for insert changes, missing fixtures, or program corrections should stay visible as unplanned loss.
Food and Beverage
Food and beverage interruption reason codes must make cleaning, changeover, packaging, material, quality, temperature, and inspection time visible. That matters because small delays can affect output, compliance, and delivery reliability.
Planned vs. Unplanned: Tag Every Code
Every reason code should also carry a planned or unplanned tag. This tag matters as much as the label, because availability can look healthy when operators put work-process stops under planned downtime.
| Tag | Use it for | Examples |
|---|---|---|
| Planned | Legally required or pre-agreed scheduled time loss | Lunch break, statutory rest break |
| Unplanned | Anything that interrupts production flow or takes longer than agreed | Tool change, cleanup outside the agreed window, product changeover, meeting, waiting for material, urgent repair |
Do not let context-dependent become a soft escape hatch. A scheduled allergen changeover is planned, but an extra allergen clean after a process mistake is unplanned. A 10-minute cleanup agreed in the production plan is planned, but an operator wiping the area every hour and logging it as cleanup is unplanned loss.
GlobalReader onboarding helps define that boundary with each factory. In one common pattern, a plant looks like it has 95% availability until tool changes, cleanups, meetings, and other work-process stops are separated from planned time; the real availability can be closer to 60%. If bonuses follow availability, loose planned-downtime rules can create a double cost: the company pays for a good number while the machine is producing less than the number suggests.
The Iterate-With-Operators Method
Your first reason-code list is only a starting point. GlobalReader usually starts by observing how each factory actually runs, because even two plants with the same machines can need different stop reasons. After launch, improve the list with operators so the system feels useful, simple, and safe to trust.
Collect feedback at the source: Ask operators which codes are unclear, missing, or too similar while the shift is still fresh. This matters because end-of-shift explanations often turn into guesses.
Watch for heavy “Other” use: Treat “Other” as a warning light, not a normal category. If operators use it often, the list is either missing a common cause or the right option is too hard to find.
For example, a wood furniture line reviewed 4 weeks of data and found “Other” made up 22% of stops. Two operator conversations showed the missing code: “veneer tear on edge-bander,” which happened 3-4 times per shift but had no label. After that code was added, “Other” dropped under 5% within a week.
Merge unused or duplicate codes: Review codes that rarely get selected and combine ones that describe the same problem in different words. A shorter list is faster to use, which improves consistency during stops.
Review usage by shift: Compare how each shift uses the same codes. If one shift logs many more planned stops than another on the same machine, check whether the work is really planned or whether the label is protecting the availability number.
Update before deeper analysis: Clean the taxonomy before using Pareto charts or 5 Whys. This is a PDCA loop for the reason-code list: plan codes, collect data, check usage, then adjust.
Once the list is clean and consistently used, turn those codes into action by starting with the losses that cost the most time.
From Codes to Root Cause: Pareto First, Then 5 Whys
Once your reason-code list is clean, use it to decide which downtime problem deserves attention first. The workflow moves from OEE loss to shop floor reason, then into root-cause work.
OEE is defined under ISO 22400, the international standard for manufacturing operations management KPIs. Availability, performance, and quality are its 3 components, and downtime analysis feeds the availability calculation.
One-glance workflow: OEE loss → reason codes → Pareto ranking → top repeat loss → 5 Whys → improvement action → re-check Pareto.
GlobalReader Analytics supports this workflow by ranking interruption categories by cumulative time lost. You can drill into machine, shift, SKU, or loss type before deciding what to fix.
Collect interruption reaosns - Start with what operators logged during actual stops. Live stop reasons are more reliable than reconstructed notes at shift end.
Rank by time lost - Sort downtime by total minutes, not by the number of stops alone.
Pick the top repeat loss - Focus on the recurring issue that costs the most production time by line, machine, product, or shift.
Run 5 Whys - Ask why until the answer points to a process, maintenance, material, or setup cause.
Assign and verify - Turn the root cause into a task for maintenance, planning, or the line supervisor. Check the same Pareto view after the change, and confirm the recurring loss shrank.
For example, a long changeover can look like an operator being slow at first. Running 5 Whys on the stop shows whether the cause sits in tooling prep, setup sequencing, standardization, or another process step.
Why did the line stop for so long? The changeover ran well over its standard time.
Why? The operator had to hunt for the correct die and tools after the machine was already stopped.
Why? The tooling was never staged or prepped before the machine came down.
Why? Setup tasks that could happen while the machine runs are being done after it stops.
Why? The changeover has never been broken into internal and external steps — the foundation of the SMED method for faster changeovers.
The fix is a planner process, not an operator conversation.
Key Takeaway: Pareto tells you where to look first. 5 Whys helps you fix the cause instead of the symptom. Still not enough? Have you tried Kaizen approach?
Automating the Capture
Good downtime analysis should not depend on operators remembering every start, stop, count, or speed change. Let the machine capture the facts automatically, then ask operators to mark the interruption reasons while the stop is fresh. The machine signal shows that production stopped; the reason-code rules decide whether that stop is planned or unplanned.
Use a simple split: machine signals record the facts, operators choose the interruption reason and add comments when needed, and Analytics shows the pattern.
| Source | What gets captured | Why it matters |
|---|---|---|
| Machine signal | Start and stop time, machine state, counts, output, and speed | You know when the machine ran, stopped, slowed down, or missed output without manual notes. |
| Operator | Interruption reason, planned/unplanned tag, scrap context, quality notes, setup changes, and product changes | You capture the context the machine cannot see while the event is still fresh, and you reduce the chance that planned downtime hides real loss. |
| Analytics | Downtime by shift, line, machine, reason, tag, and order | You can trust the data at shift end and act on the pattern the next morning. |
GlobalReader keeps that hardware-to-operator-to-Analytics flow connected in practice. See it in the free demo with sample production data.
FAQ
-
You should start with a small interruption reason list grouped into clear default clusters (8-12 max), such as setup, failure, maintenance, breaks, and material. Each group can hold a few common reasons, and operators can add comments when the fixed choice needs more context.
If you need more detail, group codes into a few clear categories first, then review whether the extra detail actually improves decisions.
-
The operator should assign the interruption reason when the machine stops, because they are closest to what happened. Automated tracking can detect the stop, but the operator adds the context the machine cannot see.
Keep the selection simple and fast. If the standard reason needs more detail, the operator can leave a comment instead of using a vague fallback like “Other.”
-
Downtime analysis should be used to fix process issues and make performance fair, not blame operators. When planned vs. unplanned rules are clear, good operators can show real output improvement instead of competing against faked availability. And the slower ones realise they do not want to be left behind and have to pick up their pace.
If operators only see the data used in arguments, they will stop giving useful answers. If they see it reducing repeat problems, improving work routines, and supporting earned bonuses, the system becomes part of improvement work.
-
You should review the reason-code taxonomy soon after launch, then regularly as the process changes. The first review should use operator feedback, unused codes, and reason patterns across shifts.
Merge codes nobody uses, rename confusing ones, and check whether different shifts are choosing different reasons for the same problem.
-
Usually, no. Tool changes, cleanups, product changes, and meetings should be unplanned unless the company has defined a fixed planned window before the shift starts.
If a cleanup is agreed as 10 minutes after a product run, track that planned window. If the same cleanup appears every hour without an agreed trigger, treat it as unplanned loss, because the time is reducing real availability.
See Where Your Production Is Losing Time With GlobalReader
If downtime reasons are guessed after the shift, your OEE numbers stay late. GlobalReader Operator feature helps you capture what happened while the stop is still fresh, starting with retrofit hardware and modular cloud software that gives you machine states, counts, stops, and output without replacing your ERP or running a long MES project.
Hardware captures the facts: ScoutBox records running state, counts, downtime, and output in real time.
Operator captures the reason: Operators choose the stop reason while the event is fresh, instead of rebuilding the shift from memory.
Analytics shows the losses: You see downtime reasons, OEE losses, micro-stops, speed losses, and trends by machine, line, shift, or order.
You can start small: Begin with the Starter Bundle, then add other tools like Maintenance, Planner, Smart Factory, notifications, or Call for Help as your needs grow.
Improvement work starts with one question: where are you really losing time? Once you can see losses by shift, machine, reason, and planned/unplanned tag, your team can fix the right problem first. GlobalReader's own positioning supports 10-25% OEE gains over time as a practical target when teams act on downtime reasons consistently, and the free demo shows how the numbers apply to your setup.
