80 Hours of Warning: Predictive Maintenance Done Right

A large food processing facility had installed a predictive maintenance system two years before we arrived. Their maintenance engineers had learned to ignore it. Not because it was wrong — it was right often enough — but because it told them a bearing was going to fail without telling them which bearing, which line, how soon, or what to do. Fifty alerts per shift, no prioritisation, no context. The engineers had developed a rational adaptation: treat all alerts as noise until something actually breaks.

This is the predictive maintenance paradox. The system works. The people don't use it. Nothing improves.

Rethinking the problem

When we audited their failure data, we found something interesting: 73% of critical failures had been preceded by an alert that was dismissed or not acted on. The problem was not detection. It was actionability.

We rebuilt the intelligence layer around a different question: not "is this asset showing anomalous readings?" but "does this asset need a maintenance intervention in the next 48 hours, and if so, what exactly should the engineer do?"

This sounds like a small shift. It required rebuilding everything.

The model architecture

The system ingests vibration, temperature, pressure, and current draw from 340 sensors across the facility. But raw sensor data is not the input to the model — it is pre-processed through an asset-specific baseline that accounts for operating mode, ambient temperature, production load, and time since last maintenance.

The model then outputs three things for each asset: a failure probability in the next 8, 24, and 72 hours; the most likely failure mode (bearing wear, lubrication degradation, imbalance, etc.); and the specific maintenance action required. An alert does not say "Conveyor 12B is anomalous." It says "Conveyor 12B: 91% probability of bearing failure at drive end within 30 hours. Recommended action: replace FAG 6305-C3 bearing. Parts in stock at maintenance bay 3."

Engineers stopped ignoring alerts within two weeks.

The 80-hour figure

After six months of operation, the average lead time between first alert and confirmed failure — on alerts that were acted on — was 80 hours. This is not a marketing number. It is the median of 47 interventions tracked during that period. Some were 20 hours. Some were 140. The median was 80.

What this means in practice: when an alert fires, there is time to schedule a planned shutdown during a low-production window rather than reacting to an unplanned failure mid-run. For a facility running 24 hours, the difference between a planned 2-hour shutdown and an unplanned 8-hour shutdown is significant.

Outcome

Unplanned downtime dropped 67% in the first two quarters. The maintenance team is now using the freed capacity to implement a full reliability programme rather than constantly firefighting. The alerts-per-shift number dropped from 50 to an average of 3 — all of which are acted on.

The maintenance engineers went from ignoring the system to asking for access on their phones.