Downtime always gets logged after the line is running again, which is exactly when nobody has time to log it well.
A machine stops. The operator scrambles to get it going and scribbles a reason on a sheet or types a quick note into the MES. Maintenance opens a work order. The supervisor mentions the lost hour at the shift handoff. Purchasing hears about the missing part on a separate thread. The number lands in a monthly report, and by the time anyone notices the same machine has stopped four Tuesdays in a row, four Tuesdays of output are already gone.
If you run a plant, you already know the total downtime figure. What you rarely get in time is the pattern behind it, and the pattern is where the maintenance decisions live. This guide is about turning downtime and maintenance reporting into something your team works every week, close to the machine, instead of a number you explain after the month closes.
What a downtime report is actually for
A downtime report earns its place when a supervisor can look at it and decide the next move while the machine is still warm. To do that, it has to answer a few plain questions without anyone opening three systems: which machine, job, and shift lost time, and how much; whether the reason is specific enough to act on or just says "breakdown"; and whether this is the first time or the same fault firing again on the same asset.
Everything else is detail. If the report cannot separate the stoppage you fix once from the one that keeps coming back, it is a finance artifact, not a maintenance tool. It tells you the plant lost time. It does not tell you what to go and fix.
A test you can run on yesterday's log
Pick one stoppage from yesterday. Ask whether a supervisor can see the reason, the linked work order, the parts it held up, and whether the same fault fired last week, all in one place. If that takes three exports and a phone call, the report is hiding the pattern you most need to see.
Walk one stoppage from alarm to running again
Before you design anything, follow one real stoppage through the plant the way it moves today. Not the version in the procedure. The messy version.
- The line stops and the machine logs an event, or the operator notices before the system does.
- The operator records a reason, usually as free text on a sheet or a quick MES entry.
- Maintenance is called and opens or updates a work order in the CMMS.
- A spare part is checked, found, or ordered, and the clock keeps running while it is located.
- The job that was on the line slips, and the delay surfaces later in the production report.
- The supervisor explains the lost time at handoff, from memory.
- The event is closed, with the reason sitting in a different place from the work order and the output loss.
The time you lose is not only the stoppage itself. It is the reconciling afterward: matching the operator's note to the work order to the output gap to the part that was short. That reconciling is the work worth removing, because it is the part that keeps the pattern invisible until the month closes.
Reason codes that mean something
The single biggest lever in downtime reporting is the reason. Most plants collect it as free text, and free text does not group. "Jam," "jammed," "material jam," and "keeps jamming" are the same fault written four ways, and a monthly report counts them as four different one-hour surprises instead of one repeat problem worth a guarding change.
A reason code earns its keep when two supervisors on two shifts would log the same fault the same way. That is a shorter list than most teams expect. You do not need forty codes. You need a small set that maps to how your maintenance team actually responds, split roughly into mechanical, electrical, material and handling, utility, changeover and setup, quality, and waiting on people or parts. The point of the category is not tidiness. It is that each category points at a different fix and a different owner.
| What the operator wrote | Clean reason | Category | What the category changes |
|---|---|---|---|
| "jammed again", "jam", "material jam" | Infeed jam | Material and handling | Groups four notes into one count; if it repeats, it points at the infeed, not another reset |
| "no air", "low pressure" | Pneumatic pressure loss | Utility | Points at the compressor or the air line, not the machine that happened to stop |
| "waiting on maint" | Awaiting technician | Waiting on people | Shows the delay was response time, not the repair itself |
| "c/o ran long" | Changeover overrun | Changeover and setup | Keeps planned setup time out of the breakdown number |
Cleaning raw notes into a short, agreed list is unglamorous, and it is where most of the value hides. Once the reasons group, the same total downtime figure starts telling you where to send a technician instead of just how much time the plant lost.
Build one record per stoppage before you add a dashboard
The first thing to build is not a dashboard. It is one record per stoppage that holds the whole story in a place everyone can see. A checklist tells you what should have been logged. A record like this tells you what happened, what it cost, and whether you have seen it before.
The first version of that record should show the event time, machine, line, job, and shift; a clean reason rather than raw free text; the linked work order and whether it is open, waiting on parts, or closed; the part or technician that held up the repair; the output the stoppage actually cost; and a flag when the same fault has fired before, with the owner of the next action. That is enough for a supervisor to act instead of report.
What a downtime review queue looks like
| Stoppage | What it cost | What the record shows | Next action |
|---|---|---|---|
| Line stoppage | Two jobs pushed past shift handoff | Operator note matches an open work order | Maintenance updates repair status before the daily review |
| Repeat micro-stops | Output lost across three runs | Same reason grouped from free-text notes on the same asset | Supervisor confirms the reason code and takes the fix |
| Repair blocked | Machine down until a replacement part arrives | Work order linked to an inventory short | Planner decides expedite or resequence |
Sort the one-offs from the repeat offenders
Once every stoppage lands in one record, the useful move is grouping by how the stoppage behaves, which is a different question from what caused it. Most downtime falls into three groups, and each wants a different response.
A one-off is a genuine surprise with a clean fix: log it, close it, move on. A repeat is the same fault on the same asset more than once, and this is the group manual reporting hides, because loose free text stops it from grouping. It is also where a small, planned maintenance change usually pays back the fastest. A blocked repair is one where the fix is known but stuck on a part, a technician, or a decision; that one needs an owner and a date, not more diagnosis.
What counts as a repeat needs a maintenance lead's judgment, and the report should make that grouping visible rather than bury it in comments. The moment the repeats stop hiding inside the total is the moment the report starts changing what the team does on the floor.
The maintenance backlog is part of the same picture
Downtime reporting and the maintenance backlog are usually kept in separate conversations, and that separation is where reliability quietly erodes. A stoppage opens a work order. Some of those work orders get closed that shift. Others get deferred, and the deferred pile is the backlog, sitting in the CMMS where the daily production review never looks.
The link matters because today's repeat stoppage is often last month's deferred work order. When a capper keeps faulting and the record shows an open inspection request that has been pushed three weeks running, you are not looking at a mysterious new problem. You are looking at deferred maintenance coming due, loudly. A downtime report that carries the backlog status next to the stoppage lets a supervisor see that connection instead of treating each fault as a fresh surprise.
You do not need a perfect backlog to start. You need the open work-order status visible against the assets that are stopping most, so the weekly review can ask the obvious question: which of this week's repeats already had a fix waiting in the backlog?
The balance you are really managing is planned versus reactive
Under the total downtime number sits a split that tells you more than the total does: how much of your maintenance time was planned against how much was reactive. Reactive work is the machine stopping and dragging a technician off whatever they were doing. Planned work is the inspection or replacement you chose to do before the machine forced the issue.
A plant drowning in reactive stoppages is a plant where the backlog is winning. When the reason codes show changeover overruns and planned inspections rather than breakdowns, that is usually a healthier week, even if the raw minutes look similar, because planned time is time you chose. The report is worth building partly so this split stops being a feeling and becomes something you can see week to week.
The honest read is not "drive reactive to zero." Some reactive work is unavoidable, and chasing a perfect number wastes the attention the floor needs. The useful read is whether the balance is drifting the wrong way on the assets that matter most, which is exactly the kind of drift a monthly total hides and a weekly grouped report surfaces early.
The weekly reliability read
All of this comes together in a short weekly review that runs off one queue instead of three exports. The read is not a meeting about every minute lost. It is a look at the assets that stopped most, the reasons that grouped into repeats, the repairs that are blocked, and the backlog items that are now overdue on those same assets.
Kept to that, the review takes fifteen minutes and produces a handful of decisions: this repeat gets a planned fix, this blocked repair gets a part expedited, this asset moves up the inspection order. The reporting routine matters more than the tooling. A simple weekly read that people actually use will beat a beautiful dashboard nobody opens between month-ends.
The test of the read is whether it shortens the gap between a stoppage and a decided next action. If the same repeat is still being rediscovered three weeks in a row, the read is describing the plant rather than changing it.
A worked example, and it is invented
Here is one week on a single line, to show the shape of the read. None of these numbers come from a real client. They are made up to illustrate how the grouping turns a pile of stoppages into a few decisions.
Picture a mid-size plant with one fill-and-pack line. Over a week, the raw log holds thirteen separate stoppage notes across three machines. On their own they look like noise. Grouped by asset and cleaned reason, they read like this.
| Asset, one week | Stoppages | What the grouping showed | Next action |
|---|---|---|---|
| Capper | Nine short stops, about 47 minutes | The same torque fault, grouped from four differently worded notes, with an inspection work order deferred three weeks | Maintenance lead schedules the deferred inspection instead of resetting it a tenth time |
| Filler | One stop, about 95 minutes | A seal failure with the work order blocked on a gasket kit that was not in stock | Planner expedites the kit and resequences the order behind it |
| Labeler | Three stops, about 20 minutes | Genuine one-offs with clean fixes and no pattern | Log and close, no follow-up needed |
The weekly total is roughly the same either way. What changed is that the capper stops moved from "annoying micro-stops" to "a deferred inspection coming due," the filler moved from "a bad day" to "a stocking gap in one gasket kit," and the labeler was correctly left alone. Three clear decisions came out of a week that would otherwise have closed as a single downtime figure with a shrug.
The data this workflow pulls together
A working downtime record usually draws from a handful of systems your plant already runs. You do not need all of them on day one, and connecting everything before the report is useful is a good way to never ship it.
| Source | What it contributes | Typical grain |
|---|---|---|
| Machine event log or historian | Timestamped stop and start, fault codes | Per event, per machine |
| MES or operator entry | The human reason and the job that was running | Per stoppage |
| CMMS work orders | Repair status, parts, technician, and the backlog | Per work order |
| ERP job and schedule | The output the stoppage cost and the order it hit | Per job or shift |
| Spare-parts inventory | Whether a missing part blocked the repair | Per part |
The first real decision is not which system to connect. It is the grain: are you reporting per stoppage, per work order, per machine, or per shift? Pick the grain that matches how your team already talks about the line at handoff, and connect the rest around it. Get the grain wrong and every later join fights you.
Where AI helps inside downtime reporting
AI is useful here once the record and the reason codes are clear, and it is useful in a narrow way: it cuts the manual assembly that keeps the pattern hidden. It can clean up free-text operator notes and group "jam," "jammed," and "material jam" into one reason. It can flag when a new stoppage matches a fault that has fired before on the same asset. It can draft the daily maintenance and supervisor note from the day's events for someone to check.
That is genuinely useful, because those are the tasks nobody has time for at shift change, and they are the tasks that decide whether a repeat gets seen this week or next month. Done well, AI makes the evidence faster to read and the weekly review shorter.
What it does not do is decide anything. It classifies, groups, summarizes, and flags. It does not decide a repair is safe, override a technician, or set a maintenance priority. If the reasons are still vague and the data is inconsistent, AI mostly helps you produce confident-looking confusion faster, so the clean record comes first and the automation comes after.
Where your team still decides
This is worth stating plainly, because it is the line that keeps the workflow trustworthy on a plant floor. The report and the AI around it exist to surface the pattern. Every judgment that carries risk stays with the people who own it.
Whether a repeat fault is worth a planned fix now or can wait is a maintenance call. Whether a machine is safe to run after a reset is a safety call, and it does not belong to a dashboard. Whether to expedite a part, resequence a job, or pull a technician off one line onto another is a decision for a planner and a supervisor who can see the whole floor. The report should make those calls faster and better informed. It should never look like it is making them.
A downtime workflow that quietly starts dictating maintenance priorities is one the maintenance team will stop trusting, and a report the floor does not trust goes back to being a monthly number nobody acts on.
The first month should make repeat problems visible
Do not try to report every asset at once. Start where the reconciling hurts most, usually one line, one cell, or a single recurring stoppage that everyone already complains about.
The first-month build
- Pick one line, one cell, or a single recurring downtime reason.
- Follow a handful of real stoppages from the operator note to the closed work order.
- Agree a short list of reason codes clean enough that two shifts would log a fault the same way.
- Stand up the record with event, reason, work-order status, part, output cost, backlog link, and a repeat flag.
- Connect the smallest set of MES, CMMS, and job data that keeps it current.
- Add one AI-assisted step, such as grouping free-text reasons, with maintenance review on top of it.
By the end of the month, the weekly review runs off one queue, the repeat offenders stop hiding inside the total, and the deferred work orders behind them sit visible next to the stoppages they cause. That is a working first version, not a finished system, and it is enough to prove whether the read changes decisions.
What tells you it is working
A falling total downtime number is the lagging result, and it arrives last. The signs you see first are on the floor. The weekly review starts from one screen instead of three exports. Repeat stoppages get named and owned rather than just counted. The gap between a stoppage and a decided next action gets shorter. Two supervisors log the same fault the same way, so the reasons finally group.
One more sign is quieter and matters as much: the maintenance team starts pulling work forward off the backlog because they can see which deferred jobs are causing this week's stoppages. When the report starts feeding maintenance decisions instead of just recording their absence, it is doing its job.
Common traps
The first trap is reporting downtime up to management instead of back to the shift that can fix it; a number that travels upward rarely changes anything on the floor. The second is free-text reasons so loose that nothing groups, which quietly guarantees every repeat reads as a string of one-offs. The third is counting minutes lost but never linking the part or work order that would explain them, so the report tells you the size of the problem and nothing about its cause.
The fourth is chasing a perfect model of every micro-stop before the big repeat faults are even named, which spends months of effort to improve the number by rounding error. The fifth is letting the report replace the walk to the machine rather than sharpen it. And the sixth, specific to plants that get the reporting right, is letting the tool start making maintenance calls that belong to the maintenance team, which is the fastest way to lose their trust and their input.
How Ubisar would build this with you
In week one we would pick one line or one recurring stoppage with you and trace a few real events from the operator's note to the work order, the output it cost, and the part or technician that held up the repair. The first thing you would have is a record that shows the event, the clean reason, the impact, the work-order and backlog status, a repeat flag, and an owner for the next action.
Over the following couple of weeks we would wire in only the MES, CMMS, job, and spare-parts data needed to keep that record current, and add AI where it clears manual work, cleaning notes and grouping reasons, while your maintenance team keeps every judgment call about priorities, safety, and the machines. This sits naturally next to the production schedule variance workflow, because downtime only matters commercially when it moves output, dates, or margin.
If your downtime number lands too late to change the work, the place to start is a single line and a few real stoppages. You can see how a month of that works in the AI, Data & Tech Implementation Service, or just get in touch and tell us which line stops the most.