End of month. You’re sitting with the production numbers.
Machine #5 made 60% of target across the month. You ask the supervisor why.
He says: “Sir, it was breaking down a lot.” You ask for the breakdown details.
He pulls out a register. Half the pages are blank. The rest say “machine problem.”
You have 30 days of lost production and zero actionable data. That is the cost of not having a proper downtime log.
- Every field a machine downtime log must have — and why each one matters
- The 9 standard reason codes used on Indian CNC and VMC shop floors
- How to calculate downtime duration in minutes using a simple Excel formula
- A worked example showing how Pareto analysis turns your log into an action plan
- Free Excel machine downtime log template — one row per event, reason code dropdown, duration auto-calculated
What you’ll learn:
Why most shop floor downtime logs are useless
Almost every Indian machining shop has some form of downtime tracking. A register on the supervisor’s desk. A shared Excel file. A column in the daily production report.
Most of them don’t work. Not because the format is wrong, but because the data going into them is incomplete, delayed, and vague.
Indian Machines
Of total downtime events were under-reported or missed entirely in manual logs before digital monitoring
Log Entry
Accounts for the majority of reason entries on Indian shop floor downtime registers — completely unactionable
Missed
Of total downtime comes from stops under 10 minutes that operators don't bother logging because they seem insignificant
Gap
Near-zero production recorded in worst-case night shifts — with downtime under-reported by 6 hours per day
The real cost: When your downtime log says “machine problem” for 3 hours, you know nothing useful. You don’t know if it was a spindle fault, a tool break, a power trip, or an operator who left early. You can’t fix what you can’t name. A log that doesn’t capture reason is not a downtime log — it’s a headcount register for stoppages.
The 8 fields every downtime log must have
A downtime log has one job: give you enough information to find the root cause and prevent the next occurrence. These 8 fields do that job. Remove any one of them and the log starts losing its value.
| Field | Format | Required? | Why it matters |
|---|---|---|---|
| Machine ID |
Text (VMC-01, CNC-03) |
Required | Without this you can't identify which machine has the worst downtime pattern. The most basic filter for any analysis. |
| Date | DD-MMM-YY | Required | Needed for trend analysis — weekly, monthly patterns. Also identifies day-of-week patterns (Monday mornings, end-of-month rushes). |
| Shift | A / B / C | Required | Shift-level analysis is critical. Night shift downtime is systematically under-reported in India. Shift column lets you compare A vs B vs C directly. |
| Start Time | HH:MM | Required | Precise start time reveals patterns — does downtime cluster around shift start, after tea break, late in the shift? Vague "morning" entries are useless for this. |
| End Time | HH:MM | Required | Required to calculate duration. Without an end time, you're estimating — and estimates are consistently wrong in both directions. |
|
Duration (minutes) |
Auto- calculated formula |
Required | The number that feeds your Pareto. Always calculate from start and end time — never ask operators to estimate duration manually. |
| Reason Code |
Dropdown (BD, TL, MAT...) |
Required | The most important field. Without a standardised reason code, every supervisor writes something different and no cross-machine analysis is possible. |
|
Resolved? (Y/N) |
Yes / No dropdown |
Required | Open issues must carry forward explicitly. A breakdown that isn't resolved at shift end will cause more downtime on the next shift — the resolved flag forces that handover. |
|
Notes / Description |
Free text | Optional | For anything the reason code doesn't fully capture. "T02 insert break — replacement tool not in stores" is far more useful than just logging TL. |
|
Operator / Logged By |
Name or ID | Optional | Accountability. When operators know their name is on the log, accuracy improves significantly. Also useful for identifying operator-specific patterns. |
The 9 standard reason codes for CNC shop floors
Breakdown
Machine fault — mechanical or electrical failure. Spindle fault, hydraulic failure, servo alarm, controller error.
Tool
Tool breakage or tool change delay beyond standard changeover time. Insert break, drill snap, tap break.
Material
Machine stopped waiting for raw material, blank stock, or WIP from a previous operation.
Setup / Changeover
Job change, fixture change, program change, or first article inspection wait — beyond planned setup time.
Operator
Operator absent, late to start, left early, or waiting for instruction. Machine ready but no operator present.
Power
Electricity outage, voltage fluctuation, load shedding. Common in many Indian industrial areas.
Planned Maintenance
Scheduled service, lubrication, inspection. The only code that represents planned downtime — filter this separately in analysis.
Quality Hold
Machine stopped waiting for QC inspection, first piece approval, or dimensional check before production can resume.
Other
Anything not covered above. Must always be accompanied by a description in the Notes column — "OTH" alone is not acceptable.
The Excel formula for downtime duration in minutes
// Cell E2 — Duration in minutes (Start Time in C2, End Time in D2) =IFERROR((D2-C2)*1440,"") // Format cells C2 and D2 as Time (HH:MM) — not text, not general // IFERROR returns blank if times aren't entered yet — keeps the sheet clean
// Total downtime minutes for the shift (events in rows 5 to 54) =IFERROR(SUM(E5:E54),0) // Count of unresolved events (Resolved column in column F) =IFERROR(COUNTIF(F5:F54,"No"),0)
Worked example: from log to Pareto to action
Step 1: The raw log (Week 32, VMC-04 only)
| Date | Shift | Start | End | Duration (min) | Code | Resolved? |
|---|---|---|---|---|---|---|
| 04-Aug | A | 09:14 | 09:52 | 38 | TL | Yes |
| 04-Aug | B | 15:40 | 16:25 | 45 | BD | No |
| 05-Aug | A | 08:00 | 08:55 | 55 | BD | Yes |
| 05-Aug | A | 11:20 | 11:34 | 14 | MAT | Yes |
| 06-Aug | B | 14:10 | 14:47 | 37 | TL | Yes |
| 07-Aug | A | 10:05 | 10:22 | 17 | SETUP | Yes |
| 08-Aug | A | 09:30 | 10:15 | 45 | TL | Yes |
Step 2: Pareto by reason code (one machine, one week)
| Reason Code | Events | Total Minutes | % of Total Downtime |
|---|---|---|---|
| TL — Tool | 3 | 120 min | 48% |
| BD — Breakdown | 2 | 100 min | 40% |
| MAT — Material | 1 | 14 min | 6% |
| SETUP — Setup | 1 | 17 min | 6% |
| Total | 7 | 251 min | 100% |
Step 3: The action that comes out of this
TL and BD together account for 88% of VMC-04’s downtime this week. That’s where the investigation starts. Three tool breaks in one week on one machine — is it the same tool, same operation, same material? Check the Notes column. Look for a pattern.
The BD on 04-Aug was unresolved at shift end. Did it cause more downtime on the next shift? The log shows it resolved by 05-Aug morning — but that means the first 55 minutes of the 05-Aug A shift was likely also BD-related. The two events are connected.
5 downtime logging mistakes that make the data worthless
1. Logging at the end of shift from memory
The outgoing supervisor fills the log at 5:58 PM before handing over. He logs 3 stoppages from a shift that had 7. The ones he remembers are the long ones. Short stops — 5 minutes here, 8 minutes there — disappear entirely. Log at the time of the event, not at shift end.
2. Vague reason entries
“Machine problem.” “Breakdown.” “Operator issue.” These entries are not reasons — they are categories. The reason a machine stopped needs to be specific enough that a maintenance engineer or IE can take action on it. Reason codes solve this. Nine codes, laminated sheet, two-second entry.
3. Not logging short stops
A 4-minute stop to clear a chip jam. A 6-minute wait for the operator to come back from the bathroom. A 3-minute coolant refill. Nobody logs these because they seem too small. Multiplied by 15 times a shift across 10 machines, these add up to hours of missing data. Log everything above 2 minutes.
4. Combining multiple events into one log entry
Three tool changes during the shift get logged as one entry: “Tool changes — 45 minutes.” This makes it impossible to see whether the three events were spread across the shift or clustered in one operation. One entry per event, always.
5. No follow-through on open issues
A breakdown gets logged as unresolved at shift end. The next shift starts, the issue is patched and the machine restarts. Nobody closes the original log entry or connects the next shift’s lost time to the same root cause. The Resolved column in the template and the carry-forward to the shift handover report exist specifically to prevent this.
Try Leanworx for Free.
For 1 Machine
Get live reports, real-time dashboards, mobile alerts, and full production visibility exactly like our paid customers.
