Predictive maintenance: what it really takes to get a warning before the breakdown

Predictive maintenance is probably the industrial use case that gets talked about most and planned worst. The promise sounds flawless: instead of replacing parts every X hours or waiting for something to break, a model watches the machine's data and warns you days in advance. What the slide deck rarely mentions is the layer underneath: for a model to warn you before the breakdown, you need labelled failure history, signals that actually measure what degrades, and a maintenance team that knows what to do with the alert.

This guide is for plant, maintenance and operations managers weighing up the jump. It covers which data you genuinely need, when it beats the calendar-based preventive plan you already have, how to build the first case, and which mistakes kill these projects before month six.

What is predictive maintenance and how does it differ from preventive?

Predictive maintenance estimates when a specific asset is going to fail based on its measured behaviour, and schedules the intervention just before. It isn't a more frequent inspection or a dashboard with extra charts: it changes the question from "how many hours has this pump run?" to "what is this pump doing that it wasn't doing three weeks ago?".

| Strategy | When you intervene | What it requires | Typical cost | |---|---|---|---| | Corrective | When it breaks | Nothing but spares and patience | Unplanned downtime, the most expensive kind | | Calendar-based preventive | Every X hours or months, per the manual | A plan and discipline | Parts replaced with useful life left | | Condition-based | When a reading crosses a threshold | Sensors and well-set thresholds | Moderate; false alerts if the threshold is poor | | Predictive | When the model estimates growing degradation | Failure history, signals and a model | High to build, low to run | | Prescriptive | The system also proposes the action | All of the above plus business rules | Only makes sense once the rest is mature |

Two caveats that save money. First, condition-based monitoring already solves a large share of the problem and costs far less. If you have never put an accelerometer on a critical motor, start there before talking about models. Second, predictive work doesn't replace preventive work, it reorders it. Cheap assets with cheap failures will stay on the calendar forever, and that's the right call.

Which data do you need before thinking about models?

This is where feasibility is decided. A predictive maintenance model learns to tell "healthy machine" from "machine heading for failure", and to do that it has to have seen failures. Three ingredients, in this order:

• Machine signals at a high enough sampling rate. Vibration, temperature, current draw, pressure, flow, running hours, RPM. Frequency matters: one reading a day will not catch bearing degradation; vibration work happens in the kilohertz range, while temperature is fine at minute resolution.
• Intervention history with dates and causes. This is the part that almost never exists in usable form. A maintenance system filled with "electrical fault" in a free-text box is no use; you need to know which component failed, when it was spotted and when it was replaced.
• Production context. The same vibration means different things depending on the product being made, the raw material batch or the shift. Without this variable, the model mistakes a product changeover for degradation.

| Failure mode | Signal that anticipates it | Realistic lead time | |---|---|---| | Bearing wear | Vibration (high-frequency bands), temperature | Weeks | | Shaft misalignment | Vibration at 1x and 2x running speed | Weeks | | Pump blockage or cavitation | Flow against pressure, current draw | Days | | Motor insulation degradation | Current, winding temperature | Weeks to months | | Leak in a hydraulic circuit | Pressure, number of pump starts | Days | | Cutting tool wear | Spindle load, part quality | Hours to days | | Conveyor or roller jam | Motor torque, camera footage of the area | Minutes to hours |

The useful question isn't "do we have data?" but "how many failures of this type have we had in the last two years, and are they properly recorded?". With fewer than ten or fifteen events per failure mode, forget training a decent supervised model: start with anomaly detection — which only needs to learn what normal looks like — and start recording properly from today. It's the same data-first logic we set out in applied predictive analytics.

A predictive maintenance project with no labelled failure history isn't an AI project: it's an instrumentation and record-keeping project, and calling it by its real name is how you budget it properly.

When is predictive maintenance worth it, and when isn't it?

The decision is economic, not technological. An asset deserves a model when three conditions hold at once:

1. The failure is expensive. Line stoppage, lost batch, contractual penalty, safety risk. If the machine stops and nothing happens for two hours, the business case isn't there. 2. The failure is progressive. Degradation leaves a measurable trail before the end. A sudden electronics failure cannot be anticipated from vibration; no model fixes that. 3. There is room to act. If the spare part takes six weeks to arrive, a four-day warning buys you little. Useful lead time is defined by logistics, not by the algorithm.

Cases where it usually isn't worth it: fleets of cheap, redundant assets, machines replaced before they degrade, plants with less than a year of data and no sensors, and any asset whose current preventive plan is running without incidents. In those scenarios the money goes further on improving maintenance data quality or on a decent availability dashboard.

A fourth criterion gets forgotten: who receives the alert. If the technician has no slack in the week's plan to bring an intervention forward, the model produces alerts nobody acts on. That's where half of these projects die, and it has nothing to do with model accuracy.

How do you build the first case, step by step?

A properly scoped first case takes three to five months, one failure mode and one asset family. Not "the plant".

| Phase | Duration | What it produces | Sign it's going well | |---|---|---|---| | 1. Pick the asset and the failure | 1-2 weeks | One critical asset, one failure mode, quantified failure cost | Maintenance and production agree on the case | | 2. Data inventory | 2-3 weeks | Which signals exist, at what rate, which failures are recorded | You know how many real events you have | | 3. Instrumentation, if missing | 3-8 weeks | Sensors added and data landing in one place | Continuous series, no multi-day gaps | | 4. Baseline with no model | 2 weeks | Simple rules and thresholds, with their hit rate | You already detect something; you have a benchmark | | 5. Model and historical validation | 3-5 weeks | Anomaly detection or prediction, tested against past failures | It would have warned on most real failures | | 6. Shadow pilot | 6-8 weeks | Alerts recorded but not triggering interventions | False positives per week at a tolerable level | | 7. Operation | Ongoing | Alert wired into the maintenance system with an owner and a deadline | Interventions genuinely get brought forward |

Phases 4 and 6 are the ones everyone wants to skip and the ones worth most. The threshold baseline tells you whether the model adds anything: if a rule like "24-hour average temperature above X" catches 70% of failures, the model has to beat that to justify itself. And the shadow pilot prevents the classic disaster of sending alerts to production from a model that cries wolf twice a shift.

How do you measure whether it works?

With maintenance metrics, not data science ones. Model accuracy is an internal number; what goes to the management meeting is different:

• True versus false alerts per week. The number that decides whether the team trusts it. One false positive a week is usually tolerable; three a day destroys credibility in a month.
• Average warning lead time. And above all, how many alerts arrive with useful lead time — enough to plan the spare part and the stoppage.
• Missed failures. The ones that got through. Review each: was a signal missing, was a label missing, or is that failure mode simply not predictable?
• Unplanned stoppages on the pilot asset against a comparable earlier period.
• Interventions avoided or brought forward. If the calendar plan can be stretched with data to back it, that's direct savings in parts and hours.
• Total cost of the case, including what it costs to maintain the sensors, the connectivity and the model. It's the line item most often underestimated, as with almost any properly budgeted AI project.

Define each metric with an owner and a frequency before you start; otherwise, three months in, the debate will be about whether the project "is going well" with nobody able to answer with a number. The criteria we use for that are in choosing KPIs people actually use.

Which mistakes kill these projects?

The ones that repeat plant after plant:

• Starting with the platform. Buying a monitoring suite for 300 assets before proving value on one. You end up paying licence fees for data nobody looks at.
• Sensoring everything "just in case". Every sensor means cabling, calibration, maintenance and one more series to watch. You instrument the failure mode you want to predict, not the whole machine.
• Trusting the free-text field. Without a closed catalogue of failure modes, the history cannot be used for training. Closing that catalogue is a month's work and it unblocks everything else.
• Ignoring production context. Models that fire every time the product changes because nobody told them changeovers exist.
• Not closing the loop. The technician intervenes, finds the root cause and doesn't record it. Without that feedback the model never improves and the project stalls at day-one accuracy.
• Confusing a dashboard with a prediction. Seeing vibration live on a screen is useful and it's a different thing. Have it by all means, but don't call a viewer predictive.
• Leaving the maintenance lead out. They know what fails, how it sounds before it fails and which alerts are credible. Without them the project is a statistics exercise. It's the same pattern we analyse in why AI pilots fail.

When the failure mode is visible — visible wear, leaks, jams, the state of a part on the line — the short route is sometimes a camera rather than a sensor; we cover that ground in computer vision in industry. And in both cases the layer holding it all up is the usual one: collecting, storing and serving time series without gaps, which is pure data engineering.

Frequently asked questions

How much historical data does predictive maintenance need?

As a rule of thumb, one to two years of continuous signals and ten to fifteen well-recorded failures of the same mode. With less, the sensible path is anomaly detection — which only needs to learn what normal operation looks like — plus labelling interventions rigorously from today so you have a base in twelve months.

Can you do predictive maintenance without installing new sensors?

Sometimes yes. Many drives, PLCs and CNC machines already log current, torque, temperature or alarms, and that data is often accessible but never collected. Before budgeting for sensors, it pays to review what the plant already generates and throws away.

What lead time do you get in practice?

It depends on the failure mode: days for hydraulics and pumps, weeks for bearings and misalignment, hours for tool wear. What matters isn't maximising lead time but making it longer than spare-part lead time plus the available stoppage window; otherwise the alert changes no decision.

What does a first predictive maintenance project cost?

It varies mostly on whether instrumentation is needed. If the signals already exist and are accessible, the cost is analysis and integration; if sensors must be fitted, add hardware, installation and connectivity, which often outweigh the model. Always ask for quotes that separate those lines and include annual upkeep.

If you have an asset causing you grief and you don't know whether your history can support a model, the useful step isn't a platform demo: it's looking at two years of interventions and the signals the machine already records, and telling you with numbers whether the case is viable or whether instrumentation comes first. That's the audit, and if you'd rather talk it through first, let's talk for half an hour and we'll tell you plainly where we'd start.