Every stoppage logged, coded and costed.
You cannot argue for maintenance budget with a feeling. Downtime tracking records each stoppage against an asset and a cause code, applies your cost per hour, and shows where the hours are actually going - including the ones lost waiting for a part.
Unplanned
125 h
Planned
68 h
Waiting on part
31 h
- CD-04Drive bearing seizure4 h 20 m
- AC-03Filter restriction, line starved1 h 10 m
- HP-02Seal kit awaited from vendor6 h 00 m
- IM-06Scheduled heater band change1 h 30 m
Hours separated into planned, unplanned and waiting on parts
Cost per downtime hour applied per line, not one blanket figure
Cause codes that point at a fix instead of at a department
In the product
Cause codes that lead somewhere.
Ranking stoppages by cause turns a vague downtime number into a short list of things worth changing. Parts availability usually appears higher than people expect.
Bearing and drive failure
46 h INR 11.5 L
Spare part not in stock
31 h INR 7.8 L
Hydraulic and seal leaks
22 h INR 5.5 L
Electrical and control faults
17 h INR 4.3 L
Lubrication related
9 h INR 2.3 L
Figures shown are an illustrative sample of the report layout, not a benchmark or a guaranteed result.
Reactive working
With condition-based planning
A shift from reactive to planned work is the outcome to aim for. Your own ratio depends on asset age, data quality and how quickly parts can be sourced.
Capabilities
What this module handles.
Fast stoppage capture
An operator logs a stop in a few taps: asset, cause, start time. Detail can be added once the line is running again.
Cost per hour by line
A packing line and a press shop do not lose the same money per hour. Rates are set per line so totals mean something.
Waiting on parts, isolated
Hours lost because a spare was not on the shelf are tracked as their own category, which is what justifies stocking decisions.
Mean time between failures
MTBF and mean time to repair are calculated per asset and per component from the log itself.
Trend reporting
Compare month on month by line, shift, asset or cause code to see whether a change actually worked.
Export for review meetings
Any view exports to CSV for the monthly production review, with the underlying event list intact.
Setup
From first login to first useful result.
- 01
Agree a cause code list
Start with eight to twelve codes that map to real fixes. Long taxonomies get ignored at three in the morning.
- 02
Set cost per hour
Enter a rate per line. Even a rough, agreed figure makes downtime comparable across the plant.
- 03
Capture stops as they happen
Operators log the stop from the line terminal or a phone. Supervisors confirm the cause on the next handover.
- 04
Review monthly by cause
Work the top two causes. The ranking usually changes within a quarter, which is the point.
Questions
Asked on the floor.
Is micro-stoppage data captured automatically?+
Short stops can be imported from line counters or a PLC export where that is available. Without a feed, the log works on operator entry, which is adequate for stoppages measured in minutes rather than seconds.
Who decides the cost per hour?+
You do. Most plants use contribution margin per hour for the line, or a simpler fully loaded cost. The figure is editable and the history recalculates.
Can we track planned downtime too?+
Yes, and you should. Separating planned from unplanned is what shows whether condition-based scheduling is shifting the balance.
How far back can we load history?+
As far as your records go. Importing even a year of past stoppages makes the first trend reports useful immediately.
