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) |
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 doing
Model your process flow, optimize staffing with Theory of Constraints, and track every shift — all in one platform. Set up in under 5 minutes.