A downtime log is not a maintenance chore. It is the ledger that tells you, in your own dollars, where the plant is quietly losing capacity. Here is why the misc line is the most expensive one on your floor, what a good log captures at the machine, and the full template to put it to work.
Read this first · Why this reaches the P&L
Downtime is not an operations metric. It is a capacity you already pay for and do not receive. Every stop is fixed cost still running, an order clock still ticking, and a promise date getting closer without product moving. The reason it rarely reaches the boardroom is not that it is small. It is that it is unmeasured, so it never shows up as a line anyone can defend cutting.
There are no invented numbers on this page. We do not quote an industry average for downtime, because an average across other people's plants would not tell you what yours is losing. Every figure here is one you produce from your own log. When you want it priced, the Downtime Cost Calculator does it on your inputs.
Why "misc" is the most expensive line on your floor
Most plants already track downtime. The problem is what they track it into. A large share of logged stops end up under a single unclassified bucket: misc, other, or a blank reason field. On paper it looks like housekeeping. In the P&L it is the single most costly line you own, because it is the one you cannot act on.
A cause you can name, you can fix. Changeovers that run long get a SMED project. A recurring bearing failure gets a PM interval. But minutes that land in misc buy you nothing. You paid for the lost capacity and got no information in return. Unclassified downtime is loss with the diagnosis deleted. It is also where the real money hides, because the stops nobody wants to write up, the two-minute jams, the waiting-on-material gaps, the undocumented tweaks, are exactly the ones that vanish into misc and then repeat every shift.
For an owner or a COO, that has a direct consequence. You cannot approve capital against a bucket. When a plant asks for a new line or a headcount, the case has to compete with a misc line that might be hiding the same capacity for free. Until downtime is classified, you are making expansion and automation decisions with your largest recurring loss blurred out.
The board-level reason to log it before you automate
Here is where it meets the AI question every manufacturer is now being pitched. Predictive maintenance, AI scheduling, and copilots all run on downtime history. If your history is a pile of misc, an AI has nothing to learn from and will confidently reproduce your blind spots. A clean downtime log is not a nice-to-have before AI. It is the training data. Spending on AI before the log is classified is buying a model of a floor you cannot yet see. The cheapest, highest-return move is almost always to fix the log first, on paper or in a spreadsheet, and let it prove where the money is before anyone buys a platform.
What a good log captures at the machine
A good downtime log is captured at the machine, at the moment the stop happens, not reconstructed from memory at end of shift. A stop written up hours later loses the one thing that makes it useful: the cause. These are the six things every entry has to capture. The headings are here in full. The exact fields, the cause code structure, and the roll-up are in the template below.
Field group 01
When: the stop, timed to the minute
Captures: duration
Start and end of the stop, timed, so duration is measured rather than guessed. Rounded-off durations are where small recurring losses disappear.
Field group 02
Where: the specific asset
Captures: location
The exact line, cell, and machine. A stop attributed to a whole line cannot be rolled up to the asset that is actually costing you.
Field group 03
What: the event and its cause code
Captures: cause
What happened, tagged to a code from a fixed list. This is the field that kills the misc bucket, and the one most logs get wrong.
Field group 04
Who: operator and notification
Captures: response
Who was running the line and who was called. This turns the log into a measure of response time, not just failure time.
Field group 05
How much: the downstream effect
Captures: loss
Units not made, scrap generated, and whether the stop starved an operation downstream. This is what converts minutes into money.
Field group 06
Follow-up: action and recurrence
Captures: closure
What was done to restart, and whether the same stop has happened before. Recurrence is the flag that tells you where a real fix pays back.
You have the six headings. The template below turns each into concrete fields, gives you a cause code structure that retires misc, and shows how to roll the log up into a Pareto and a dollar figure. Enter your work email to open it here.
The full template
Get the full downtime log template.
You have seen the six field groups above. Enter your work email and the full template opens right here on this page, with the exact fields, the cause code structure, and the roll-up. A copy goes to your inbox to hand to the floor.
Every field to log, laid out row by row, ready to build in a spreadsheet
A cause code structure, planned and unplanned, that retires the misc bucket
How to roll the log up into a Pareto by cause and a dollar figure you can defend
Work email only. We use it to send the template and nothing else you did not ask for. Unsubscribe anytime.
Unlocked. The full template is open below, and a copy is on its way to your inbox. If you checked the box, a Harmony engineer will reach out to help stand it up.
Part 01 · The entry
Every field, one row per stop
One row for each stop. Build these as columns in a spreadsheet, or as fields on a tablet at the station. The order matters less than logging every one, every time.
Date & shiftThe production date and shift. Lets you roll losses up by shift and spot a pattern that belongs to a crew or a time of day rather than a machine.
Asset IDThe specific line, cell, and machine number. Use the tag that is already on the equipment so entries match your asset list.
Start timeWhen the stop began, to the minute. If it is estimated, mark it estimated so the roll-up can weight it.
End timeWhen the line ran again. Start and end give you duration without anyone doing math at the station.
DurationCalculated from start and end. Keep it as a field so short stops are never rounded to zero.
Planned?A simple yes or no. Planned stops belong in the log too, so unplanned loss is measured against a real denominator.
Cause codeOne code from the fixed list in Part 02. This is the field that ends the misc bucket. No free text here.
Cause detailA short free-text note for the specifics, after the code is chosen. Detail supports the code, it does not replace it.
OperatorWho was running the line. Not for blame, for follow-up, and to measure training gaps honestly.
Notified / responderWho was called and who cleared it. Turns the log into a measure of response time, not just failure time.
Units lostProduct not made during the stop, at standard rate. This is the field that converts minutes into money.
Scrap generatedAny product scrapped as a result of the stop or the restart. Restart scrap is a real and often missed cost.
Downstream starved?Whether the stop starved or blocked another operation. A short stop on a constraint costs the whole line.
Recurring?Whether this stop has happened before on this asset. The single most useful flag for deciding where a fix pays back.
Action takenWhat restarted the line, in one line. Enough to tell a quick reset from a real repair when you roll it up.
Why this shape
The fields split into three jobs. When and where let you attribute the loss to a real asset and shift. The cause code lets you group and fix it. Units, scrap, and downstream let you price it. A log missing the last group tracks minutes but never reaches the P&L, which is why so many downtime logs get kept and never used.
Part 02 · Cause codes
The structure that retires "misc"
A fixed list, split first into planned and unplanned, then into categories. Keep the list short enough to pick from at the station in seconds. Adapt the wording to your process, but hold the structure, and delete misc entirely.
PLN · ChangeoverPlanned change of product, tooling, or format. The biggest planned bucket, and the first candidate for a SMED project.
PLN · MaintenanceScheduled PM, cleaning, or sanitation. Planned and expected, but still capacity, so still logged.
PLN · No demandIdle by schedule: no order, no crew, break. Separates chosen idleness from lost capacity.
UNP · MechanicalBreakdown, jam, tooling failure, wear. The classic unplanned stop and the one PM programs target.
UNP · Electrical / controlsPLC fault, sensor, drive, power. Often short and repeated, and often lost to misc because nobody logs a two-minute reset.
UNP · Material starvationWaiting on upstream material, components, or supply. A logistics loss wearing a machine's uniform.
UNP · Quality holdStopped for an out-of-spec check, hold, or rework. Ties downtime to your scrap and quality story.
UNP · Operator / processSetup error, adjustment, waiting on a decision, training gap. Named plainly so it can be trained out, not hidden.
UNP · Utilities / facilityAir, water, steam, HVAC, external power. Shared-cause stops that hit several assets at once.
UNP · ExternalCarrier, customer hold, weather, anything off-site. Real loss, but not yours to fix on the floor.
The one rule that makes it work
There is no misc code, on purpose. The moment a catch-all exists, it fills up, because it is the fastest box to tick. If a stop truly does not fit, the honest move is to add a named code, not to reach for other. A short, complete, named list is what turns a downtime log from a record into a diagnosis. When you later put AI on this data, these codes become the labels it learns from, so the discipline you keep now is exactly what a predictive model inherits.
Part 03 · Roll-up
From a log to a dollar figure
A log nobody rolls up is a filing cabinet. The roll-up is where it earns its keep, and it is three moves you can do in a spreadsheet.
Pareto by causeSum duration by cause code and sort descending. The top few codes almost always hold most of the loss. That ranked list is your improvement backlog, in priority order, with no opinion involved.
Pareto by assetSum duration by asset. It answers a different question, which machine is costing you, and often points at a single constraint that deserves capital before anything else does.
Convert to dollarsMultiply lost hours by your own fully loaded line rate, and add the value of scrap and of any downstream starving. Now the log speaks the language of the P&L, on your numbers, not an industry average.
What to do with the number
Once the loss is ranked by cause, by asset, and priced, three decisions get easier and more defensible. Where to spend: the top of the Pareto is the case for a project, a PM interval, or a changeover effort, ahead of a new line. Whether to automate: if most of the loss sits in short, repeated, unlogged stops, that is the pattern predictive tooling is built for, and now you have the history to train it. What to say to the board: a dollar figure with a cause behind it is a number you can defend, unlike a misc line nobody can.
To put a price on it without building the sheet, run your numbers through the Downtime Cost Calculator. It takes your rate and your logged hours and returns the annual cost, so you can size the problem before you spend a dollar fixing it.
Where a downtime log sits in the bigger picture
Logging downtime cleanly is a small, early piece of a larger arc every plant moves through, from paper to a live layer to AI. It belongs at the very start, because a classified log is exactly the kind of digitized, connected, unified record everything later depends on. Get the log right and you have done, on one metric, the work the whole sequence asks for on all of them.
Phase 1
Lay the Data Foundation · Digitization
Every pen-and-paper record digitized at the station, every software system connected, and all of the data unified into one live layer. A clean downtime log is one of the first records to move here.
Phase 2
Production & Operations Scale
Factory operations turn proactive: live sensors and machine data, the AI scheduling board, predictive maintenance before failure, trained on the very history the log now holds.
Phase 3
AI-Native Operations
Agents across the floor and the back office act on the live layer: quality signals, reports, copilots. Humans approve.
Not sure the floor is ready for any of that yet? The AI Readiness Checklist is the plain list you work through to find out, and the Downtime Cost Calculator prices the losses this log surfaces.
Rather have someone stand the log up with you?
Building the log is the first week of a Harmony pilot, on-site, with forward-deployed engineers doing the classifying alongside your team. A Harmony pilot is a fixed $15,000 to $20,000 one time, runs 4 to 6 weeks, with working software in your hands by the end of the pilot. Phase 1 first, because that is the order it has to happen in. See what the live layer looks like.
