At the end of the shift, the filler’s fault log shows an interlock and the operator’s sheet says the line was blocked. Production downtime tracking starts by establishing when scheduled production stopped and when it resumed. Once you have that interval, attach the controller events and the operator’s explanation to the same record (each can tell you something the other cannot).
Review the interval, the production schedule, and the reason code before assigning follow-up. Otherwise a fault that fired during a downstream blockage can send maintenance to investigate the wrong machine. If the stop crosses a shift change, keep its event ID and allocate minutes to each shift from the same interval.
Let the machine clock establish the interval
Choose the asset or line you’re measuring and define a production restart. A return to an enabled or ready state can precede the first production cycle, so use the transition or output signal your team agrees will close the stop. For manual collection, have the operator record the observed times and retain the time the entry was submitted. A report entered after a break should still describe when the stop occurred.
The MTConnect Institute’s execution model distinguishes ready, active, and interrupted states. The OPC Foundation’s PackML model includes a first stop-reason event and describes suspension when upstream product is unavailable or downstream equipment blocks the machine. These are examples of what connected equipment can report. Document how each actual machine signal maps to your reporting state, including what happens during a dry cycle or a test run.
Intersect the stop with scheduled production before reporting lost time. If a stop runs through a planned break, keep the whole source interval and calculate the overlap with scheduled production. For an open stop, show elapsed time through the report cutoff and label it open. If the feed goes offline and leaves the restart unobserved, flag the time as uncertain and attach any independent operator evidence rather than treating the end of the feed as a restart.
Keep one stop record with separate evidence
In this hypothetical example the filler is scheduled to run throughout the interval. Its production mode indicates a stop at 09:42:10, an interlock alert appears later, and the first confirmed production cycle comes at 09:55:40. The operator records that the downstream packer backed up. The shift supervisor confirms that sequence against the packer log.
| Fields to keep | Example value | How the field is used |
|---|---|---|
| Event, asset, line, shift, work order | Stop 071, filler F2, line 4, day shift, WO-412 | Tie edits and source records to the same incident |
| Observed stop and restart, including timezone | 09:42:10 to 09:55:40 plant local time | Measure the event and allocate shift minutes |
| Schedule version and covered time | Day shift schedule, fully within production window | Separate elapsed from scheduled time lost |
| Controller state, alarm IDs, operator observation | Production stopped; interlock at 09:44; packer backed up | Preserve different pieces of evidence without adding durations |
| Reason, evidence status, reviewer, revision | Downstream blocked; confirmed by supervisor; original alert retained | Route the action and reproduce a prior report |
This stop contributes thirteen minutes and thirty seconds to the filler’s machine log. If the packer is down from 09:40 to 09:52, the two machine logs still describe their own stops. When the line’s output signal confirms continuous lost production from 09:40 to 09:55:40, report fifteen minutes and forty seconds of line downtime. Summing the filler and packer durations would count some of that line time twice.
Assign stop codes that tell the next owner where to look
Start with codes that route a review. A machine fault can go to maintenance. A material shortage can go to the person supplying the line. Separate upstream starvation from downstream blockage because the same filler can stop for either condition, and the action belongs at opposite ends of the line. A planned changeover can use its own code even if its scheduled minutes stay visible in your local loss report.
Record the first observed signal separately from the reviewed reason. Keep an explicit unknown code for real stops where the evidence is incomplete, and use a separate feed-gap status when the stop itself cannot be confirmed. If you revise a code, save who changed it, when, and which record changed their mind. Repeated use of an unknown code for the same shift or asset can show where operator instructions or signal coverage need work.
Separate repeated short stops from duplicate observations. Collapse successive records when the observed state shows one continuous stop. If it restarted and stopped again, keep distinct events, even if you group them later to investigate a recurring failure. For reports that use a duration threshold to distinguish availability loss from speed loss, document it beside the overall equipment effectiveness formula.
Inspect a shift’s source records
Bring a supported event export into Permute and check which timestamps, asset IDs, and reason fields came through.
Review elapsed minutes and open causes at shift handoff
The outgoing supervisor can check open intervals, duplicates, and unknown codes against the operator log before signing off. The incoming supervisor needs the current state, any already-assigned action, and the evidence that would close it. Review the largest durations alongside recurring short stops. A long planned changeover and frequent faults can take similar time but call for different work.
During a weekly review, assign a named owner to one recurrence or unresolved loss and attach the events that justify it. Save what changed and compare the same machine and production window after the fix. If the plant also needs operation progress and work-order history, see MES system for the execution records that can supply that context.
Where Permute fits in the shift report
Permute is the context layer we sell between operating data and the AI tools people use. We can match supported machine-history exports, shift calendars, and operator sheets on the plant’s asset identifiers. The raw times and source reason codes remain visible alongside the reviewed result.
We use the plant’s stop boundaries, shift rules, and review status to produce the same duration and cause breakdown for a supervisor’s report and an authorized AI query.
A reliability lead can ask which stops on line 4 are still missing an approved reason and get the matching intervals, source references, and review status. Access follows the permissions on the underlying data.
Keep machine control and cause approval at the plant
We read records made available from supported sources. We do not write back into systems of record, control machines, or certify root causes. Missing transitions need another observation or a verified correction from the plant.
Keep the stop and its review together
Production downtime tracking gives a shift team the observed interval, its overlap with the production schedule, and the best evidence for the cause. A state transition sets the clock, while the reviewed code identifies who should investigate. The filler and packer can each keep their own record. Count the independently confirmed line-output stop once in the line report. Leave uncertain times or causes visible at handoff so the next owner knows what to confirm.
Review how your stop data reaches the shift report
Bring one disputed stop, its machine log, and the schedule that determines which minutes count.
Questions about recording production stops
How do you record a stop that crosses midnight?
Keep the observed stop and restart as one timestamped interval. Use a timezone-aware shift calendar to calculate the minutes assigned to each shift, even if the plant’s reporting day differs from the calendar date.
Can an older machine use a manual downtime log?
Yes. Use the same stop record fields and identify the observer and time of entry so a late note does not masquerade as a controller timestamp.
Should every brief stop appear in the shift review?
Retain short events when your collection can detect them and apply a documented review threshold. If a recurring stop is filtered out of the summary, the raw events still let you see how often it happens.