Most IoT fleets already collect the data that predictive maintenance is supposed to run on: temperature, vibration, current draw, cycle counts, uptime. The gap is rarely the sensors. It is everything between the telemetry stream and a model that tells someone, correctly and early enough to act on, that a specific unit is going to fail.
That gap is where predictive maintenance projects stall. Not because the maths is exotic, but because the inputs a model needs are organisational, not technical: a clean record of what actually broke, when, and why. Before committing engineering time to it, it is worth being precise about what “predictive” requires and what it costs when the model gets it wrong.
Predictive is not the same as alerting
An alerting system tells you a value has crossed a threshold right now: a temperature sensor above 80°C, a battery below 10%. That is useful and it is comparatively simple to build well. Predictive maintenance is a different claim: it says a unit is likely to fail in some future window, before any single reading looks abnormal. It is inferring a trend or a pattern across multiple signals, not checking one number against one limit.
Conflating the two is the most common reason these projects disappoint. A dashboard that flags anomalies is genuinely valuable and much cheaper to deliver. Call it what it is rather than dressing it up as prediction, because the two have different data requirements and different failure modes.
The input a model needs is failure history, not sensor volume
A supervised model — the kind that learns to distinguish “about to fail” telemetry from “normal” telemetry — needs labelled examples of both. That means a reliable record of actual failures: which unit, what component, what date, ideally what the failure mode was. Most fleets do not have this in a usable form. Failures show up as a support ticket, a field engineer’s note, or a customer complaint, scattered across systems that were never designed to be joined against telemetry by timestamp and device ID.
Building that join is unglamorous work and it usually takes longer than building the model itself. If a fleet has fewer than a few dozen recorded failures of a given type, there is not enough signal to train anything meaningful, and the honest options are an unsupervised anomaly detector (which flags “unusual” without knowing if unusual means “about to fail”) or a threshold-based rule set tuned from domain knowledge rather than learned from data.
Threshold rules, statistical models, or machine learning
These are not stages of maturity you progress through. They are different tools for different amounts of failure history and different failure mechanics.
- Threshold and rate-of-change rules work when an engineer already knows the failure mechanism — vibration amplitude rising past a known limit, a battery’s discharge rate accelerating. No failure history is needed, only domain expertise, and the rules are auditable, which matters when a customer asks why a unit was flagged.
- Statistical process control (control charts, moving averages, seasonal decomposition) works well for equipment with a clear normal operating baseline and gradual drift. It needs enough historical telemetry to define “normal” per unit or per unit class, but not necessarily labelled failures.
- Supervised machine learning earns its complexity only with real labelled failure history across enough units and enough failure events to generalise. Below that threshold it will overfit to noise and produce false alerts that erode trust in the system faster than no system at all.
Most fleets are better served starting with the first or second option and only moving to the third once enough labelled data has actually accumulated, which itself only happens if failure reporting is disciplined from day one.
False positives are the real cost, not model accuracy
A model’s headline accuracy figure is close to useless on its own. What matters is the balance between false positives (flagging a healthy unit, sending someone out for nothing) and false negatives (missing a real failure). That balance is a business decision, not a machine learning one, and it changes per component.
A false negative on a component that is cheap to replace and safe to run to failure costs little. A false negative on something that causes an unplanned outage or a safety incident costs a great deal. A false positive that sends an engineer on an unnecessary site visit has a direct, quantifiable cost per event, and if the model generates too many of them, the maintenance team will start ignoring the alerts entirely, which quietly kills the project. Setting the alert threshold is therefore a conversation with whoever owns the maintenance budget, not a default left at whatever the model produces.
What it changes in the data pipeline
Predictive maintenance also has infrastructure consequences beyond the model:
- Telemetry retention needs to be long enough to cover the run-up to past failures, not just the last few days for live alerting.
- Feature computation (rolling averages, rate of change, time since last maintenance) has to run consistently in both training and live inference, or the model degrades quietly in production without anyone noticing until it stops flagging anything useful.
- A failure-reporting workflow needs to exist and be used, because the model’s accuracy a year from now depends on the labels being fed back in today.
- Someone needs to own retraining. Equipment ages, failure modes shift, and a model trained once on year-one data will drift.
None of this is exotic engineering, but it is ongoing engineering, and it does not stop once the model ships.
When it is not worth building
It is reasonable, and often correct, to decide against it. Predictive maintenance is a poor fit when the fleet is small enough that failure counts will never reach statistical significance, when components are cheap enough that run-to-failure plus a spare parts buffer is simply cheaper than any monitoring system, or when maintenance is already scheduled on a fixed interval that comfortably beats the failure curve. In those cases, an anomaly alert on the handful of readings that actually matter delivers most of the value for a fraction of the build and ongoing maintenance cost.
A checklist before committing
- Do you have, or can you build within a reasonable time, a reliable joined record of failures against telemetry by device and timestamp?
- Do you have enough recorded failures of the specific type you want to predict — realistically dozens, not a handful?
- Have you costed a false positive and a false negative separately for the component in question?
- Is there a named owner for retraining and for feeding new failure reports back into the dataset?
- Have you compared the build and running cost against simply running to failure or maintaining on a fixed schedule?
- Would a threshold-based alert on the two or three signals that matter most already catch most of what you are trying to catch?
If most of these have honest answers, predictive maintenance is worth scoping properly. If several do not, the right next step is usually better alerting and better failure records first, and revisiting prediction once that foundation exists.