Why Downtime Analysis Matters
Downtime is the most visible and measurable form of lost capacity. Every minute your bottleneck is down is a unit you will never make. Yet most plants have only a vague idea of why their equipment stops — "it was down for maintenance" or "we had some issues." Without precise categorization, you cannot improve.
Structured downtime analysis transforms vague complaints into specific, actionable improvement targets. It answers: what stops the equipment most often, for how long, and what can we do about it?
Planned vs. Unplanned Downtime
| Type | Definition | Examples | Goal |
|---|---|---|---|
| Planned | Scheduled stops that are part of the production plan | Changeovers, PM, breaks, meetings, cleaning, material replenishment | Minimize through SMED, efficient PM, structured handoffs |
| Unplanned | Unexpected stops that disrupt the schedule | Breakdowns, quality holds, material shortages, operator absence, utility failures | Eliminate through TPM, poka-yoke, supplier development |
The 6 Big Losses
The TPM framework categorizes all equipment losses into 6 types, grouped by the OEE factor they affect:
| OEE Factor | Loss | Description | Countermeasure |
|---|---|---|---|
| Availability | 1. Equipment Failure | Breakdowns that stop production | PM/PdM, AM |
| 2. Setup & Adjustment | Changeovers, startups, adjustments | SMED, standardized setup | |
| Performance | 3. Idling & Minor Stops | Brief stops <5 min (jams, sensor trips, feeding errors) | Root cause analysis, error-proofing |
| 4. Reduced Speed | Running below rated speed | Restore design conditions, operator training | |
| Quality | 5. Process Defects | Scrap and rework during steady-state production | Capability improvement, SPC |
| 6. Startup Rejects | Defects during warmup, changeover, startup | Standardized startup procedures, standard work |
Building a Downtime Coding System
A coding system is essential for consistent categorization. Without it, the same event gets logged differently by each operator ("breakdown" vs "machine down" vs "maintenance issue") making analysis impossible.
Example Coding System
| Code | Category | Description |
|---|---|---|
| BD | Breakdown | Unplanned equipment failure requiring maintenance |
| CO | Changeover | Planned product change (setup + adjustment) |
| PM | Planned Maintenance | Scheduled PM activity |
| MS | Material Shortage | Line waiting for raw material or components |
| QH | Quality Hold | Stopped for quality investigation or containment |
| MN | Minor Stop | Brief stop <5 min (jam, sensor, feeding) |
| SP | Speed Loss | Running below rated speed |
| NP | No Plan | No production scheduled (no demand) |
| ST | Startup/Shutdown | Warmup, cooldown, end-of-shift shutdown |
| OT | Other | Does not fit above categories (review periodically — if >10%, add a code) |
The prose on this page carries no dataset, so every number below comes from the one worked example the page does contain: the six default rows of the Interactive Demo further down, each of which the prose also names, and which the reader can perturb to see this figure's argument bend. Mechanical Failure 8 × 45 = 360 min; Changeover 12 × 25 = 300; Material Shortage 5 × 60 = 300; Operator Absence 3 × 90 = 270; Quality Hold 6 × 20 = 120; Minor Stops 20 × 5 = 100 — 54 stops and 1,450 minutes in the month. Minor Stops' five-minute average is the page's own definition of the code ("brief stop under 5 min"), and Changeover is the only planned code of the six, which is why it alone is drawn as a hollow square. Everything else is arithmetic on those twelve numbers: Minor Stops is 20 of 54 stops (37%) but 100 of 1,450 minutes (7%); Operator Absence is 3 of 54 stops (6%) but 270 minutes (19%). The top two by count are 32 of 54 stops and only 400 minutes (28%); the top two by minutes are 660 minutes (46%) from just 20 stops. Changeover and Material Shortage tie at 300 minutes and are shown in the demo's own row order. The countermeasure phrases in the corners are the page's own, from the 6 Big Losses table.
Analyzing Downtime
✅ Good Downtime Tracking
- Every stop coded in real time by the operator
- Simple, clear coding system posted at every station
- Weekly Pareto review at T2 meeting
- Top causes get formal RCCA projects
- Trend tracked monthly — downtime % is declining
❌ Downtime Guessing
- "We were down for a while" — no duration, no code
- Data entered at end of shift from memory
- 50 codes that no one remembers
- "Other" is the #1 category
- Data collected but never analyzed or acted on
🎯 Key Takeaway
You cannot reduce downtime you do not measure. Build a simple coding system (10-15 codes), train operators to log every stop in real time, and Pareto the results weekly. Focus improvement on the top 2-3 causes. When those improve, re-Pareto and attack the new top causes. Combine with OEE tracking on your bottleneck to see how downtime reduction translates directly into throughput recovery.
Interactive Demo
Edit downtime events to see how categories, MTBF, MTTR, and availability metrics update. Identify the top loss drivers from your data.
Stop reading, start modeling
Model your process flow, run simulations, optimize staffing with TOC math, and test your knowledge with 107 interactive checks — all in one platform.