Guide 11 min read

Downtime analysis with evidence

Build downtime analysis around operating evidence: scheduled run time, event windows, reason codes, alarms, notes, impact, and next checks.

By WizeeMind Team Published on June 18, 2026 Updated on June 29, 2026

Operations team reviewing downtime evidence from plant systems and logs

The line is running again, which is exactly when the downtime story starts to get worse.

At 10:14, packaging stopped. At 11:01, it restarted. The first reason code says “operator adjustment.” The schedule is still tight, maintenance has no open breakdown order, and quality has not placed the batch on hold. A dashboard can close that event in one tidy row.

The floor feels less tidy. The alarm list shows a short low-pressure warning before the stop. The operator note mentions product skew after restart. A work order from the previous evening changed a pneumatic fitting near the transfer point. The reason code may be true: an operator did adjust the line. It may also be the least useful fact in the packet.

Downtime analysis should not begin with the label typed after recovery. It should begin with sourced operating evidence. APQC defines unplanned machine or equipment downtime as a share of scheduled run time, not as a mood or a blame category (APQC downtime benchmark). ISA-95 exists because plant information crosses enterprise, operations, and control layers that need shared structure (ISA-95). A serious downtime record has to respect both ideas.

Treat the reason code as evidence, not verdict

Reason codes are useful. They give teams a common vocabulary for losses, make shift comparisons possible, and stop every daily meeting from becoming oral history. But a reason code is a classification. It is not the event itself.

That distinction matters because most reason codes are entered under pressure. The line has just restarted. The next order is waiting. The operator has to pick from a menu that may not match the real sequence. The supervisor wants a clean chart before the production meeting. A code such as “operator adjustment” may describe the visible action that ended the stop, while the event window points to pressure instability, material tracking, or a maintenance change that deserves a different follow-up.

APQC’s measure anchors the question in scheduled run time and unplanned disruption, which keeps the analysis tied to operating loss instead of post-event labeling (APQC downtime benchmark). NIST’s operations-driven performance work is a useful companion because it focuses on collecting and analyzing operational data to identify performance problems (NIST performance measurement). Put together, they say something practical: the code belongs in the evidence set, beside time, state, alarms, notes, maintenance records, and impact.

The first packet for a downtime event should include scheduled run window, event start, event end, restart time, line state before the stop, reason code, person or system that entered it, alarm records, operator notes, relevant work orders, quality status, and the next verification question. That packet does not slow analysis. It stops the easiest explanation from becoming the official one before anyone has checked it.

There is a small discipline hidden here. Do not ask, “What was the cause?” too early. Ask, “What evidence supports the current classification, and what evidence limits it?” The first question invites a confident story. The second creates a reviewable record.

For WizeeMind, the output should read like an evidence table, not a verdict. “Current code: operator adjustment. Supporting evidence: operator adjusted guide rail at 10:16. Limiting evidence: low-pressure alarms at 10:11 and 10:22; recent fitting replacement near transfer point; post-restart product skew note.” That is not indecision. That is analysis doing its job.

Rebuild the event window before debating cause

The event window is more than start and end time. It is the operating sequence around the stop: last known normal state, first abnormal signal, stop declaration, manual actions, alarms, setpoint changes, interventions, restart attempts, and return to stable running. If the team skips that sequence, the conversation jumps straight from “line stopped” to “somebody caused it.”

This is where plant data behaves less like a spreadsheet and more like a flight recorder. A flight recorder does not decide why the incident happened. It preserves timing, signals, commands, and context so trained people can reconstruct what changed. Downtime needs the same humility. The trace has to survive the production meeting.

NIST’s operations-driven performance project connects smart manufacturing work to system characterization, performance issue identification, and diagnostic frameworks (NIST performance measurement). ISA-95 helps locate where each piece of that trace may live, since production schedules, MES records, control signals, maintenance orders, and quality status often sit in different layers (ISA-95).

For the 47-minute stop, the timeline could look like this: 10:07, line running at standard rate. 10:11, low-pressure alarm appears and clears after 18 seconds. 10:14, MES records downtime start. 10:16, operator adjusts guide rail and clears skewed product. 10:22, low-pressure alarm repeats during restart attempt. 10:29, maintenance checks local air supply but opens no breakdown order. 10:48, line restarts at reduced rate. 11:01, standard rate returns and downtime closes.

That sequence changes the next action. The reason code is still part of the story, but it no longer owns the story. A supervisor may decide to keep the code and add a pressure check. Maintenance may inspect the replaced fitting. Quality may review units made during unstable restart. The same 47 minutes now produce better work.

WizeeMind should force the event window into visible form: source system, timestamp, record identifier, plant object, and claim supported. An alarm supports an abnormal signal. A note supports an observed symptom. A work order supports recent activity. None of those alone proves cause. The packet should make that boundary obvious, because a polished paragraph can make weak evidence look stronger than it is.

Bring maintenance records close, but do not turn proximity into proof

Maintenance evidence can explain downtime. It can also distort a review when the team treats a nearby work order as a cause without checking mechanism. A fitting replaced the night before a pressure alarm is a lead. It is not proof. A closed work order may show that work occurred, but it may not show that return-to-service checks matched the later failure mode.

NIST’s maintenance strategy work describes maintenance data as coming from both human-generated records, such as work orders, and equipment-generated sources, such as monitoring and diagnostic data (NIST maintenance strategies). Douglas S. Thomas, Economist at the National Institute of Standards and Technology, frames the value of advanced maintenance in manufacturing as a cost problem that includes direct maintenance, repair, downtime, lost sales, rework, defects, and the maintenance strategy behind those losses (NIST maintenance economics). That is a useful warning: the analysis has to preserve categories instead of blending everything into one convenient cause.

A downtime packet should bring maintenance evidence into the same view with clear labels. It should show work order number, status, asset identifier, requested task, repair code if present, technician notes, parts adjusted or replaced, measurements taken, completion time, and checks performed before return to service. It should also show what the record does not prove.

In practice, this prevents two unfair outcomes. The first is blaming maintenance because a work order happened nearby. The second is excluding maintenance because no breakdown order was opened during the event. Informal checks happen. Naming mismatches happen. Asset hierarchies are messy. A local station might be known by one name in maintenance, another in MES, and a third in a procedure. The NIST standards landscape report points to the broader smart manufacturing problem: systems need standards and shared understanding across product, production, and business information (NIST standards landscape).

WizeeMind should therefore avoid “maintenance caused the stop” unless the evidence chain supports it. Better wording is sharper and more honest: “The prior fitting replacement is relevant because it occurred on the same local air path within 16 hours of repeated low-pressure alarms. No record yet confirms pressure stability after the repair.” That sentence gives maintenance a fair next check and gives operations a reason not to close the event too fast.

Connect downtime to quality and throughput impact

A downtime event is not only a clock problem. A line can restart and still leave product questions behind: units made during unstable speed, packaging handled during a jam, inspection comments after restart, rework, scrap, hold status, or batch documentation gaps. If the packet ignores those records, the plant may solve the time loss while missing the operating consequence.

OEE makes this visible by treating availability, performance, and quality as separate parts of equipment effectiveness, with quality loss distinct from time and speed loss (OEE factors). APQC’s downtime measure narrows the downtime metric to unplanned disruption of scheduled run time, which is useful for benchmarking but not enough for event closure (APQC downtime benchmark). The plant needs both views. The downtime clock says how long production was interrupted. The quality and throughput view says what the interruption did.

For the 47-minute stop, the time loss is clear. The impact is not. Did any units run between the reduced-rate restart and stable operation? Were skewed products removed, inspected, reworked, or scrapped? Did the batch record capture the unstable window? Did quality need to review the product after the second low-pressure alarm? These are not academic questions. They decide whether the stop is a small availability event, a repeat-loss signal, a quality concern, or a cross-functional review.

WizeeMind should attach a minimum impact layer to every downtime packet: product, order, batch or lot if available, quantity before stop, quantity during restart, rejects, rework, scrap, hold or release status, inspection comments, and procedure steps tied to restart or line clearance. The assistant should not make the quality decision. It should show whether quality evidence exists and whether a qualified role needs to review it.

This is also where timeline matters again. A quality note after restart may be unrelated background. It may also be the first visible effect of the same mechanism that caused the stop. The packet should label it as observation until a record ties it to affected product. That label sounds small. It keeps the analysis from turning every nearby comment into proof.

The useful closeout is not “47 minutes lost.” It is “47 minutes lost, line restarted at reduced rate, product skew noted during recovery, no hold currently recorded, post-restart units not yet linked to inspection result.” That is the kind of sentence another person can act on.

Make missing and conflicting signals visible

Downtime packets often fail because they look too clean. They hide the gaps that actually decide confidence: unmatched asset names, alarm clocks out of sync with MES, reason codes entered late, maintenance notes with no measurements, quality status unavailable, or restart checks recorded in a shift note but not in the controlled system.

Missing evidence is evidence about confidence. It should appear in the packet instead of being buried in silence. NIST’s operations-driven work points toward methods and diagnostic frameworks for identifying performance issues, which implies a repeatable process rather than a meeting shaped by whoever speaks first (NIST performance measurement). The NIST standards landscape report makes the same point at system level: smart manufacturing needs information exchange and understanding across many domains (NIST standards landscape).

A simple confidence view helps. High confidence: the line lost 47 minutes of scheduled run time. High confidence: the selected reason code is operator adjustment. Medium confidence: low-pressure alarms are related to restart difficulty. Low confidence: the prior fitting replacement contributed to the stop. Not verified: whether units after restart need additional quality review.

That format is more useful than a single score. A percentage can look scientific while hiding bad inputs. A confidence statement tied to source limits shows people what to check next. It also protects the plant from the strange certainty that dashboards sometimes create. Green rows feel finished. Real events rarely are.

WizeeMind should expose conflicts in plain language. If MES says “operator adjustment,” alarms point to pressure, maintenance records point to recent work, and quality notes mention skew, the assistant should not smooth those signals into one confident summary. It should say the classification is supported by an operator action but limited by pressure and maintenance evidence. Then it should recommend a verification step: compare low-pressure timing, inspect the replaced fitting, confirm guide alignment, and check product disposition before final closure.

That is the contrarian rule of downtime analysis: a messier packet can be a better packet. The goal is not to make the event sound resolved. The goal is to make the real state of knowledge visible before the event disappears into a monthly chart.

Close with a controlled next check

Downtime analysis should end with a next check, not a dramatic conclusion. The next check may be small: confirm the alarm did not repeat on the next run, confirm the reason code still fits after maintenance review, confirm no quality concern appeared after restart. For repeat stops, the next check may be a short review with operations, maintenance, and quality. For high-impact stops, it may trigger formal investigation.

The closeout should answer seven questions. What scheduled run time was disrupted? What evidence supports the current code? What evidence challenges or limits it? What was checked before restart? What remains unverified? Who owns the next check? When should the event be reopened?

ISA-95 helps because those answers cross system boundaries, and the standard gives teams a common integration frame for enterprise and control systems (ISA-95). NIST’s maintenance economics report adds the cost frame: downtime analysis has to account for downtime, repair, defects, rework, and lost sales where those apply, not only the minutes on the chart (NIST maintenance economics).

A WizeeMind closeout for the opening event should look something like this: “The 47-minute stop is currently coded as operator adjustment. Evidence confirms scheduled run disruption, guide adjustment after the stop, low-pressure alarms before and during restart, recent pneumatic fitting work near the transfer point, and operator notes about product skew. Next verification: review local pressure stability, inspect the replaced fitting, confirm guide alignment, and check whether post-restart units require quality review before final closure.”

That answer does not pretend to own the decision. It gives the supervisor, operator, maintenance lead, and quality role the same evidence surface. It leaves authority with accountable people.

This is the standard WizeeMind should help plants reach: fewer unsupported stories, less searching across systems, clearer source limits, and a next check that a qualified person can verify. The first reason code may still be right. It just has to earn its place.