"Predictive maintenance" is the phrase that gets industrial IoT projects funded in India, and it's also the phrase that gets them quietly shelved eighteen months later.
The pitch is irresistible: sensors on your machines, AI watching the data, an alert before anything breaks. No unplanned downtime. The vendor deck always has the same graph going up and to the right.
We've built these systems. Some earned their cost back in months. Others should never have been started — and the difference was almost never the quality of the model. It was whether the arithmetic worked before anyone wrote a line of code.
Here's how to tell which one you're looking at.
Three strategies, and predictive isn't automatically best
Every maintenance programme is one of three things.
Reactive — run it until it breaks, then fix it. Cheap until it isn't. Rational for a ₹4,000 pump you keep two spares of. Catastrophic for the compressor that halts a production line.
Preventive — service on a fixed schedule regardless of condition. Every 500 hours, every quarter. This is what most Indian plants actually run, and it's better than its reputation. It's also wasteful in a specific way: you replace parts with life left in them, and you still miss failures that don't respect the calendar.
Predictive — monitor actual condition, act when the data says the machine is degrading. Least waste, most capability, highest setup cost.
The mistake is treating these as a maturity ladder with predictive as the destination. They're a portfolio. In every plant we've worked in, the right answer is reactive for most assets, preventive for many, and predictive for a small, carefully chosen set.
Choosing that set correctly is the entire game.
The arithmetic that decides it
Predictive maintenance pays when this holds:
(cost of a failure × failures avoided per year) > (sensors + installation + platform + model + the engineer who responds to alerts)
Both sides get estimated badly, in opposite directions.
The left side gets inflated. People count the repair cost and stop. The real cost of a failure is repair plus lost production for the full downtime, plus scrapped in-process material, plus expedited freight on the replacement part, plus penalty clauses if you missed a delivery commitment. For a line running three shifts, downtime cost usually dwarfs repair cost by an order of magnitude.
But "failures avoided" gets inflated too. You will not avoid all of them. A good system catches a majority of degradation-type failures and essentially none of the sudden ones. A bearing wearing out is predictable. A power surge frying a control board is not.
The right side gets underestimated. Sensor hardware is the cheap part, and the only part most estimates include. What actually costs money:
- Installation — running cable in an operating plant, or fighting battery replacement schedules if wireless. Often more than the sensors.
- Connectivity — plants are hostile to wireless. Metal, motors and concrete kill signals in ways no site survey fully predicts.
- The alert responder. This is the line item that sinks projects. An alert nobody acts on is worth nothing. Somebody must own the response, have authority to stop a machine, and be trusted enough that operations listens. If you can't name that person, stop here — you're buying a dashboard, not maintenance.
The precondition nobody mentions: you probably can't train a model yet
Here's the uncomfortable part. Supervised failure prediction needs examples of failures — labelled, timestamped, with sensor data covering the run-up.
Most Indian plants don't have this. What they have is a maintenance register, often on paper, saying "Pump 3 — bearing replaced — 14/03." No sensor data from before the failure, because the sensors weren't there. No precise timestamp. No record of what the machine was doing.
And critically: a well-maintained machine fails rarely. A critical asset might fail twice a year. Two examples a year is not a training set. You'd need years of instrumented history to accumulate enough labelled failures for a supervised model on a single asset class.
This is why so many predictive projects stall at the pilot. The sensors go in, the dashboard looks impressive, and then the data scientist asks for failure examples and there are four, three of which predate instrumentation.
The way out is to stop trying to start with prediction:
Anomaly detection instead of failure prediction. Don't predict when it will fail. Detect that it is no longer behaving like itself. Learn the machine's normal operating signature and flag deviation from it. This needs no failure examples at all — only a few weeks of normal running. It's unsupervised, far simpler, and catches most of what matters.
Physics beats ML at the start. Decades of reliability engineering already tell you what a failing bearing looks like: characteristic vibration frequencies. Motor current signature analysis finds rotor problems. Thermal rise indicates friction and electrical faults. These are known, well-documented relationships. A threshold on the right derived feature outperforms a neural network trained on four failures — and your maintenance engineer can actually explain why it fired, which is what makes it trusted.
Instrument now, model later. The instrumentation is the durable asset. Start collecting properly labelled data immediately, including making failure logging disciplined and digital. In two years you'll have a real training set. Teams that skipped this step are still two years away, permanently.
The concept that decides whether any of it is useful
Reliability engineers call it the P-F interval. P is the point a developing fault first becomes detectable. F is the point the machine actually fails. The gap between them is your lead time.
Everything hinges on that gap being long enough to be useful.
If a bearing shows detectable vibration change eight weeks before seizure, that's a superb candidate — time to order the part and schedule the swap during planned downtime. If a component gives ninety seconds of warning, monitoring it changes nothing except how well-informed you are while it breaks.
And the lead time must exceed your logistics reality, not a textbook's. In India that often means: how long to get the spare part? If a critical spare is a six-week import and detection gives four weeks, the alert doesn't prevent downtime — it tells you earlier that downtime is coming. Useful, but a much smaller benefit than the business case assumed.
So the qualifying question for each asset is: does this fail gradually, in a way we can detect, with enough warning to actually do something, given how we really operate?
Where it genuinely pays in India
Patterns we've seen work:
Continuous-process manufacturing. Textiles, cement, chemicals, paper. Line stoppage cost is enormous, machines run constantly, and failure modes are well-understood rotating-equipment problems. The strongest case by a wide margin.
Cold chain. Compressor failure doesn't just cost a repair — it destroys the cargo. Pharma cold chain adds regulatory consequences. Here the cost of failure is so high that even modest detection accuracy pays.
Distributed assets with expensive site visits. Telecom tower DG sets, water pumping stations, solar inverter farms, agricultural irrigation. The win often isn't avoided failure at all — it's avoided truck rolls. Knowing which of 200 remote sites needs a technician is worth a great deal when each visit costs thousands and a wasted trip is pure loss.
Commercial building HVAC. Chillers are expensive, degrade gradually, and waste energy long before failing. Energy savings alone often justify monitoring, with failure prevention as upside.
Where it usually doesn't pay:
- Low-value assets with cheap spares and quick swaps. Keep a spare. That is your strategy.
- Single-shift operations with slack capacity. If a machine going down means catching up tomorrow, downtime cost is small.
- Plants without a maintenance function to act on alerts. Fix the process first. Software cannot supply organisational capacity.
- Very new plants. Everything is under warranty and nothing has failed. Instrument for the future, but don't expect near-term returns.
A staged path that doesn't require faith
Stage 1 — Rank your assets by failure cost. Before any hardware. List critical machines and estimate the full cost of an hour down for each. This list is usually short — often five to ten assets carry most of the risk. Everything after this is about that short list.
Stage 2 — Instrument the top few and just watch. Vibration, temperature, current draw. No models, no predictions. Collect and store the data, and make failure logging digital and disciplined from day one. This stage builds the asset everything later depends on.
Stage 3 — Threshold and anomaly alerts. Apply known engineering thresholds and simple statistical anomaly detection. Most of the practical value shows up here, and it's the cheapest stage. Many programmes should stop here permanently and be right to.
Stage 4 — Model, if the data earns it. Once you have genuine labelled failures across enough assets, supervised prediction becomes possible. Approach it as an improvement to a working system, not as the thing that makes it work.
Most Indian industrial clients we work with belong at stage 2 or 3. Vendors sell stage 4. That gap is where budgets die.
Four ways these projects fail
Alert fatigue kills it in month three. Tuned too sensitively, the system cries wolf, operators start ignoring it, and within weeks it's furniture. Start with thresholds so conservative you catch only obvious problems, then tighten. A system trusted because it caught three real problems beats one that flagged thirty and was wrong twenty-seven times.
Nobody owns the response. Covered above, and it remains the top killer. Name the person before you buy sensors.
The pilot proves nothing. Six months on two machines that don't fail. No failures avoided, no ROI, project cancelled. Define success upfront as something measurable inside the window — detected anomalies confirmed by inspection, for instance — not "failures prevented," which you can't observe in a short pilot.
Sensor placement is treated as trivial. Vibration data quality depends heavily on mounting location and rigidity. A badly mounted accelerometer produces confident, meaningless numbers. This is a specialist decision, not a job for whoever has a drill.
The honest summary
Predictive maintenance in India pays when you have expensive downtime, gradual failure modes, enough lead time to act given real logistics, and a maintenance team that responds to alerts.
When those four hold, returns are large and fast. When they don't, no amount of model quality rescues it.
Start by ranking assets by the cost of an hour of downtime. If that list is short and the numbers are large, you have a case. If failure costs are modest, keep spares on the shelf and spend the budget elsewhere — that's not a failure of ambition, it's the correct answer.
This is the third article in our IoT series. The architecture case study covers what happens to cloud costs at scale, and polling vs event-driven covers the data pipeline underneath all of this.
Want an honest assessment?
We build industrial IoT and condition-monitoring systems for Indian manufacturers and asset operators — and we'll tell you when the numbers don't support it. Two weeks, fixed scope: asset ranking, failure-mode review, and a written recommendation with the cost model behind it.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our IoT work · WhatsApp: +91 9677749648