FREE TOOL
Machine downtime log, reason codes and work order from an alarm
A machine downtime log records every stop: the date, the machine, when it stopped, how many minutes it was down, a reason code and what the operator saw. Kept for a few weeks, it tells you which machine and which cause cost the most time, and which stops keep coming back. Log stops here or paste them from Excel, get a Pareto by reason and by machine, flag any machine that stops three times for the same reason in 7 days, and print a blank log for the floor. Type an alarm code and the operator’s note and the tool picks the reason code and drafts the work order. Plants running Morsa skip the form entirely: it builds the log from the machines and the shift chat.
Updated October 21, 2026
What a downtime log should record
| Column | Why it matters | Example |
|---|---|---|
| Date and shift | Patterns by shift and by day of the week | 2026-10-19, second shift |
| Machine | Ranks machines by lost time | Lathe 6 |
| Start and end, or minutes | The size of the loss; MTTR comes from it | 22:10, 40 min |
| Reason code | Groups stops so they can be counted | TL02 Chip control |
| Operator note | The detail a code cannot hold | chips wrapped on bar feeder, cleared x2 |
| Action taken | What fixed it, for next time | replaced insert, reset |
| Planned or unplanned | Only unplanned stops count as failures | Unplanned |
Record every stop over a set threshold, usually 5 minutes, and count shorter ones as minor stops. A threshold everyone knows keeps the log honest; a log that only has the big breakdowns hides the small stops that add up to more.
Downtime reason codes
A short list beats a long one: Vorne’s guidance is that downtime reporting is more consistent and more useful with a smaller list of reasons. This list has 29 codes in 10 groups. Planned codes (preventive maintenance, changeovers, breaks) are tracked but are not failures, so they stay out of MTBF.
| Code | Reason | Group |
|---|---|---|
| PL01 | Preventive maintenance | Planned (planned) |
| PL02 | Changeover or setup | Planned (planned) |
| PL03 | Break, meeting or training | Planned (planned) |
| PL04 | No work scheduled | Planned (planned) |
| PL05 | Engineering trial | Planned (planned) |
| ME01 | Mechanical breakdown | Mechanical |
| ME02 | Hydraulic or pneumatic fault | Mechanical |
| ME03 | Spindle, bearing or drive | Mechanical |
| ME04 | Bar feeder or loader fault | Mechanical |
| ME05 | Conveyor or chip conveyor jam | Mechanical |
| EL01 | Electrical fault | Electrical and controls |
| EL02 | Control, PLC or CNC alarm | Electrical and controls |
| EL03 | Sensor or switch fault | Electrical and controls |
| EL04 | Power loss | Electrical and controls |
| TL01 | Tool breakage or wear | Tooling and workholding |
| TL02 | Chip control (chips wrapping or packing) | Tooling and workholding |
| TL03 | Fixture or workholding | Tooling and workholding |
| MA01 | Waiting for material | Material |
| MA02 | Wrong or defective material | Material |
| MA03 | Material handling (forklift, crane) | Material |
| QU01 | Quality hold or first-piece approval | Quality |
| QU02 | Out of tolerance adjustment | Quality |
| QU03 | Scrap or rework | Quality |
| PE01 | No operator | People |
| PE02 | Waiting for maintenance | People |
| UT01 | Air pressure | Utilities |
| UT02 | Coolant | Utilities |
| MS01 | Minor stop or jam (under 5 minutes) | Minor stops |
| OT01 | Other or unknown | Other |
Code the cause, not the symptom. A bar feeder alarm caused by chips wrapping on the bar is a chip control problem (TL02), and the fix is the insert, the feed and the coolant, not the feeder. The tool reads it that way too.
From an alarm and a note to a work order
Type the alarm as the control shows it and the operator’s words, in English or Spanish. For “1023 BAR FEEDER FAULT” and “chips wrapped on bar feeder again, cleared x2” the tool picks TL02 Chip control (chips wrapping or packing) and, because the log has two earlier chip stops on Lathe 6 this week, drafts a high priority work order:
Lock out and tag out before anyone reaches into the machine.
Clear chips, check the chip breaker insert, feed and coolant; review the setup notes.
Find the root cause, not just the reset: this is stop 3 for this reason on Lathe 6 in 7 days.
Run a first piece and get it checked before the machine goes back to production.
It adds a tool room request (“Tool room: check stock of the inserts and tools for Lathe 6 and send spares to the machine.”) and a note to email the machine builder’s service team with the alarm log. Change the code if it is wrong, copy the work order, download it as a PDF or add the stop to the log.
How to read the log
Sort by minutes, not by count. The Pareto lists reasons and machines by lost minutes with a running total. The top two or three usually hold most of the time.
Look for repeats. Three stops for the same reason on the same machine inside 7 days is a pattern, not bad luck. The log flags it.
Split planned from unplanned. Changeovers and PM are time you chose to spend; reduce them with SMED and better PM, not with repairs.
Turn the top cause into one project. Use root cause analysis on it, fix it, and watch its minutes fall in the next weeks of the log.
Feed the numbers forward. Unplanned minutes and stop counts give MTBF and MTTR; the minutes times your margin give the cost of downtime; planned and unplanned time feed OEE availability.
The modern way: the log writes itself
Paper logs and spreadsheets fail the same way: the stop happens at 2 AM, the note gets written at the end of the shift, if at all, and the reason says “machine down”. Plants that run an AI operations agent such as Morsa stop asking operators to fill in forms. Overnight, Lathe 6 is down 40 minutes. Morsa takes the alarm code from the machine and the operator’s note from the shift chat (“chips wrapped on bar feeder”), codes it, sends maintenance a work order for tonight and asks the tool room for chip breaker inserts. It is the third time this week, so the machine builder’s service team gets an email with the alarm log attached. The 6 AM brief shows the 40 minutes with its reason, and the fix is already moving. People approve; nobody retypes.
Limits
The log reads up to 2,000 stops and keeps them in your browser only. Dates are US order (10/20/2026) or ISO (2026-10-20).
A row the tool cannot read is listed with the reason. It is never guessed.
The reason code from a note is a suggestion from keywords and, when the server is reachable, a check of the wording. Confirm it with the person who fixed the machine.
The work order is a draft. Follow your own lockout and tagout procedure.
Common questions
What is machine downtime?
Any time a machine is scheduled to run and is not running. Unplanned downtime is breakdowns, jams, waiting for material or people; planned downtime is changeovers, preventive maintenance and breaks.
How do you calculate downtime in production?
Add up the minutes of every stop in the period, from the moment the machine stopped to the moment it made a good part again. Downtime percent = downtime / planned production time x 100. 40 minutes in an 8-hour shift is 8.3%.
Should I track downtime in Excel or software?
Excel works for one area if someone keeps it up. It breaks when the notes come in late or not at all. Machine monitoring captures the minutes; the reason still has to come from people. An AI agent like Morsa gets the reason from what operators already say in the shift chat.
How many reason codes should we have?
Few enough that an operator can pick one in a few seconds: 20 to 30, in groups. Add a code only when “Other” keeps holding the same cause.
Related tools
WHERE MORSA FITS
When a machine stops, the reason and the fix should already be moving.
Morsa reads the alarm from the machine and the operator’s note from the shift chat, codes the stop, opens the work order, asks the tool room for parts and, on the third stop in a week, emails the machine builder with the alarm log. It works in Teams, WhatsApp, email or whatever your floor already uses.
