Last updated: October 2026
Equipment downtime tracking is the practice of recording every time a machine or line stops, how long it stays down, and why. To do it well, capture start and stop times automatically from the machine, have the operator add a reason code from a short standard list, store each stoppage as one event with the same data fields, and review a weekly Pareto chart to attack the biggest causes first.
This guide is for plant managers, continuous improvement leads and maintenance managers who want a practical method, whether you start with a clipboard or with sensors. It covers what to record, how to classify stoppages, how to run a downtime Pareto analysis, and when a spreadsheet stops being enough.
What equipment downtime tracking covers (and what it does not)
Machine downtime tracking usually means one asset: a press, a CNC, a filler. Equipment downtime tracking is broader. It covers every machine and line in a plant, with the same rules, so stoppages can be compared across areas and shifts.
A complete program answers four questions for every stoppage:
- When did the machine stop, and when did it restart?
- How long was it down?
- Why did it stop (reason code)?
- What was the impact on planned output?
Downtime is the largest input to the Availability factor of OEE. If you need a refresher on how Availability, Performance and Quality combine, see OEE explained: overall equipment effectiveness.
How to track machine downtime in 6 steps
- Define “down”. Write one rule, for example: “a machine is down when it produces no good parts for longer than X seconds during planned production time.” Without this rule, two shifts will report two different numbers.
- Separate planned from unplanned time. Breaks, scheduled maintenance and no-demand periods are planned stops. Track them, but keep them out of unplanned downtime.
- Capture start and stop times automatically if you can. Machine status signals (a current sensor, a PLC tag, an OPC UA variable) give exact timestamps. Manual logs tend to miss short stops and round long ones.
- Ask the operator for the reason, not the duration. People are good at explaining why a machine stopped and poor at timing it. Let the system time the event and let the operator pick a reason code.
- Use a short starter list of reason codes. Begin with 8 to 15 codes grouped into a few categories, then refine after a month of data.
- Review weekly and act on the top causes. A downtime log that nobody reviews is just a cost. Hold a short weekly review built on a Pareto chart, assign owners and check the effect the following week.
Downtime tracking data fields, reason codes and Pareto analysis
The quality of your analysis depends on the structure of each record. Every machine stoppage should be stored as one event with the same minimum downtime event data fields, whether it lives in a spreadsheet or in software.
Minimum data fields per downtime event
| Field | Type | Example | Why it matters |
|---|---|---|---|
| Event ID | Unique text or number | DT-2026-10-0412 | Prevents duplicates and lets you link the event to a work order. |
| Machine or line ID | Text (from a fixed list) | PRESS-07 | Lets you compare assets and roll data up to cells, lines and plants. |
| Machine status | Category | Stopped, running, idle, setup | Separates real stoppages from changeovers and starved or blocked states. |
| Start time | Date and time | 2026-10-14 09:42:10 | Anchors the event to a shift, product and operator. |
| End time | Date and time | 2026-10-14 10:05:40 | Needed to compute duration and restart behavior. |
| Duration | Number (minutes) | 23.5 | The value you sum in a Pareto. Calculate it, never type it. |
| Planned or unplanned | Yes/No | Unplanned | Keeps breaks and scheduled maintenance out of the loss analysis. |
| Reason category | Category | Breakdown | First level of the Pareto, for a quick view of loss types. |
| Reason code | Code (from a fixed list) | BRK-HYD (hydraulic fault) | The level where corrective actions are decided. |
| Shift | Category | B | Reveals shift patterns in training, staffing or handover. |
| Product or part number | Text | P-4410 | Shows whether some references cause more jams or longer setups. |
| Operator comment | Free text (optional) | “Pump pressure dropped after warm-up” | Gives maintenance context the code alone cannot carry. |
Two rules make this table work. First, use drop-down lists for machine, status and reason fields so the data can be grouped. Second, calculate duration from timestamps instead of asking people to estimate it.
A starter set of reason codes
Keep the first version short. A practical starter set uses five categories:
- Breakdown: mechanical, electrical, hydraulic or pneumatic, controls.
- Setup and changeover: product change, tooling change, cleaning.
- Minor stoppage: jam, sensor trip, misfeed.
- External wait: no material, no operator, upstream or downstream blocked.
- Planned stop: break, scheduled maintenance, no demand.
For a complete, multi-level list with definitions, see our downtime reason codes library.
Download the free asset
Instant download. No email confirmation needed.
How to run a downtime Pareto analysis, step by step
- Pick a period and scope. For example, one line over the last four weeks of planned production time.
- Filter out planned stops. Keep only unplanned events.
- Group by reason code and sum the duration. Total minutes is usually the right measure. Also count events, because frequent short stops and rare long breakdowns call for different fixes.
- Sort from largest to smallest.
- Compute the cumulative percentage of total downtime for each code in the sorted list.
- Draw the chart: bars for minutes per code, a line for the cumulative percentage.
- Select the few codes that make up most of the loss (often around 80% of the minutes) and open a root-cause analysis on the first one or two.
- Repeat the same Pareto next month with the same filters, so you can see whether the actions worked.
Hypothetical example: over four weeks a packaging line logs 1,800 minutes of unplanned downtime. Sorted by reason, “film jam” accounts for 620 minutes, “changeover overrun” 410 minutes and “no material” 300 minutes. Those three codes represent about 74% of the total, so the team starts with film jams and changeover overruns and sets the remaining codes aside for now.
Downtime tracking spreadsheet vs software
Many plants start with a spreadsheet, and that is a reasonable first step. The comparison below shows where each approach fits.
| Criteria | Paper or spreadsheet | Automated tracking software |
|---|---|---|
| Start and stop times | Written by hand, often rounded | Captured from machine signals |
| Short stops | Usually missed | Captured as separate events |
| Reason codes | Typed or written, inconsistent spelling | Chosen from a fixed list on a tablet or terminal |
| Pareto analysis | Built manually, often weekly at best | Updated continuously, by shift, product or machine |
| Multi-machine or multi-site view | Hard to consolidate | Built in |
| Setup effort | Low | Moderate: sensors or connectors plus configuration |
| Best for | One or two machines, a first pilot of the method | Several lines, recurring losses, OEE programs |
A useful sign that you have outgrown the spreadsheet: the team spends more time cleaning the log than acting on it. If you are at that point, our guide to downtime tracking software covers how to evaluate tools in detail.
How to choose your approach: a quick checklist
- Can you capture machine status automatically on your oldest machines, not only on the newest PLC-controlled ones?
- Can operators enter a reason in a few taps at the machine, during the shift?
- Are reason codes standardized across lines and sites?
- Do short stops appear as separate events, or are they hidden in “slow running”?
- Can you produce a Pareto by machine, shift and product without manual work?
- Does the data feed directly into Availability and OEE?
- Can IT accept the connection method (sensor, PLC, OPC UA) and the data hosting?
- Who owns the weekly review, and is that meeting already on the calendar?
A short worked ROI example (hypothetical)
All figures below are hypothetical and for illustration only. A line runs 2 shifts of 8 hours, 5 days a week, for 48 weeks: 3,840 planned hours per year. Unplanned downtime is 12% of planned time, or about 460 hours.
After structured equipment downtime tracking and a monthly Pareto review, the team removes a quarter of the top cause and shortens changeovers. Suppose total unplanned downtime falls from 12% to 9%. That frees about 115 hours of production per year on that line. If each hour of output is worth $1,500 in contribution margin (a hypothetical value; use your own), the recovered capacity is worth about $172,000 per year, before counting avoided overtime.
Run the same calculation with your own numbers. If you want to go further, the Availability gain translates directly into OEE points.
How TEEPTRAK supports equipment downtime tracking
TEEPTRAK is the company that publishes this guide. Our platform is built around the method described above:
- Automatic stoppage detection on any machine, using non-intrusive sensors on legacy equipment and PLC or OPC UA connectors on modern equipment. Live data within 48 hours of installation.
- Operator reason entry on a terminal at the line, from your own reason code list.
- Real-time Pareto, Availability and OEE by machine, shift and product.
- JEMBA AI to help identify root causes across machines and shifts.
- MoniTrak for a consolidated, multi-site view of downtime.
TEEPTRAK runs in 700+ plants in 30 countries, with customers including Hutchinson, Safran, Alstom and Stellantis. Across customer deployments, the average gain is +29 OEE points, and Hutchinson raised OEE from 47% to 72%.
If you are comparing platforms, see our overview of OEE software for 2026.
Other approaches US plants compare
Buyers also look at tools with different focuses: MachineMetrics focuses on CNC and machine-tool connectivity, Vorne XL offers a plug-in display and monitoring device for individual lines, Evocon targets simple OEE tracking for small and mid-size plants, and Redzone centers on team engagement and connected workforce routines. The right fit depends on your machine mix, number of sites and how much you want operators involved.
How we evaluated the method in this guide
The recommendations here reflect what we see when deploying downtime tracking on production lines. We judged each practice on concrete criteria:
- Accuracy of start and stop times versus manual logs.
- Time the operator needs to enter a reason during the shift.
- Consistency of reason codes across shifts and sites.
- Speed from raw events to an actionable Pareto.
- Effort for maintenance and IT to install and maintain.
Equipment downtime tracking FAQ
What is equipment downtime tracking?
Equipment downtime tracking is the systematic recording of every stoppage on every machine and line: when it started, when it ended, how long it lasted and why it happened. The goal is to find and remove the largest causes of lost production time.
How do you track machine downtime accurately?
Capture start and stop times automatically from machine signals, ask operators only for the reason code, store each stoppage as one event with standard data fields, and review a Pareto chart.
What data fields should a downtime event include?
At minimum: event ID, machine ID, machine status, start time, end time, duration, planned or unplanned flag, reason category, reason code, shift, product and an optional operator comment.
How many downtime reason codes should we start with?
Start with about 8 to 15 codes in a few categories such as breakdown, setup, minor stoppage, external wait and planned stop. Refine the list after a month of real data, removing codes nobody uses.
When should we move from a downtime tracking spreadsheet to software?
Move to software when you track several machines, when short stops go unrecorded, or when the team spends more time cleaning the spreadsheet than acting on the results.
How long does it take to start tracking downtime with TEEPTRAK?
TEEPTRAK delivers live data within 48 hours of installation. Most teams start with a 90-day Guided pilot on one line, supervised by TEEPTRAK engineers, before extending to other lines.
Start tracking downtime on one line
Measure every stoppage on one of your lines for 90 days, with TEEPTRAK engineers supporting your team from baseline to decision.
0 Comments