Build Logs & Industry Playbooks
Predictive Maintenance: Start With Thresholds, Not ML
By Mudabbir Hasan, Co-founder · Published · Last updated
Start predictive maintenance with clean timestamped data and tiered threshold alerts on your most critical assets. Add simple statistics such as moving averages next, and move to machine learning only when failure patterns are complex or thresholds produce too many false alarms. Log every failure and maintenance outcome from day one, and send alerts to the people and system that act on them.
Where do most predictive maintenance projects start wrong?
They start with the model. The three guides we read, from Ubidots (an IoT platform), Ignitec (an engineering consultancy) and StellixSoft (a software firm), each sell something, and each says the same thing: machine learning is not where to begin. StellixSoft puts it plainly: not every predictive maintenance system needs machine learning from day one.
Thresholds first, machine learning later
Thresholds
- Clear limits you can explain
- Quick to start
- Guided by vibration standards such as ISO 20816
- Moving averages need no failure history
Machine learning
- Complex failure patterns
- Interacting signals
- Needs failure labels from maintenance outcomes
- Compare it with the rules in shadow mode
Which savings figures should you ignore?
Ignitec cites downtime cuts of up to 50 percent and maintenance cost reductions of 18 to 25 percent, but admits the 50 percent figure is hard to trace to a single primary study and that the other comes from one company's programme measured against its own history. Ubidots' numbers are illustrative or unsourced. StellixSoft gives no statistics. Use your own downtime records to build the case.
What order should you build things in?
- Pick the assets. Ignitec advises starting with critical machines, not easy ones, and piloting on two or three with the costliest unplanned downtime.
- Collect the right data. Ubidots says to capture timestamped time-series data, such as runtime, cycle counts, vibration, temperature and energy, plus failure and maintenance logs, and to start simple, even with an on and off signal.
- Set a baseline. Ignitec says to budget several weeks to months of data collection, and warns against borrowing thresholds from another machine or a vendor default.
- Set tiered threshold alerts. Ubidots bases limits on standards or experience with similar equipment, and Ignitec says threshold alerting following ISO 20816 remains a valid starting point. Ubidots cites ISO 10816 for vibration limits. ISO 17359, per Ignitec, structures the whole programme.
- Add simple statistics. Ubidots compares the live value with a moving average of the last N readings. A short window reacts fast but gives false alarms, and a longer one is steadier. This needs no failure history.
- Run in shadow mode. StellixSoft suggests comparing predictions against real outcomes before any alert reaches a person.
- Move to machine learning when it is justified: complex failure patterns, interacting signals, or thresholds that give too many false alerts or miss early degradation.
Build in this order
- 1
Pick two or three critical assets
- 2
Log timestamped data, failures and repairs
- 3
Collect a baseline
Weeks to months.
- 4
Set tiered threshold alerts
- 5
Add simple statistics
A moving average of recent readings.
- 6
Run in shadow mode
- 7
Move to machine learning if justified
Why do failure labels matter?
StellixSoft says the most valuable dataset combines sensor signals with maintenance outcomes, and that lacking failure labels or technician feedback makes it hard to validate a model. Models that estimate remaining useful life need run-to-failure data. Anomaly detection, which learns a machine's normal behaviour, can work with few labels as long as there is enough normal data. The cheapest thing you can do on day one is to log every failure and every repair in a consistent format.
Log from day one
Timestamps on every reading
Runtime, cycles, vibration, temperature, energy
Every failure and every repair
Technician notes
What is the accuracy trap?
Ubidots warns that accuracy alone can mislead when failures are rare. In its hypothetical example, a model reporting 70 percent accuracy on a machine that fails 1 percent of the time tells you little about whether it catches the failures. Judge a model on how many real failures it catches and how many false alerts it raises, not on one accuracy figure.
What happens after the alert?
Ignitec names a common pitfall: treating maintenance staff as an afterthought, so alerts land where nobody looks and the maintenance system is never integrated. Route alerts to the dashboards and work-order system your team already uses. Ignitec also says that if a system can trigger shutdowns or work orders without human review, it should be secured as a safety-adjacent control system.
What does this look like in our work?
Our IoT fleet monitoring case describes a platform that takes live telemetry from distributed equipment into real-time fleet dashboards with location and status, historical analytics and maintenance tracking, plus threshold-based alerts and an AI agent that reads the telemetry for early warning signs. Every alert and recommendation is backed by historical analytics so a manager can see the pattern behind it. The engagement is confidential, so the case page limits itself to what the client allows.
What should you do first?
- Choose two or three critical assets and write down the cost of their unplanned downtime.
- Start logging runtime, the main sensor readings and every repair, with timestamps.
- Set warning and alarm thresholds and measure the false alarm rate for a few weeks.
- Decide who receives each alert and what they do with it, before you add anything clever.
Sources
- Predictive maintenance with IoT: a practical guide for engineers, Ubidots (accessed 2026-10-10)
- Predictive maintenance systems for IoT sensors: a practical guide, Ignitec (accessed 2026-10-10)
- Predictive maintenance with IoT and machine learning, StellixSoft (accessed 2026-10-10)
Related guides
Talk to an engineer about your project
Start with a free project call. We learn what you are building and recommend the right next step, with no pitch.
Book a call