Early Fault and Incident Detection: Anomaly Detection for Assets and Utilities

There is a moment in every maintenance career where you stop being impressed by the failure that was dramatic and start being impressed by the failure that never happened. A chiller that ran for years without a catastrophic trip, a substation transformer that got attention while it was merely warm rather than after it burned, a water main repaired on a Tuesday morning instead of flooding a basement at 2am on a Sunday. None of those are stories anyone tells at a conference, because nothing exciting occurred. That is exactly the point. Anomaly detection, done properly, is the discipline of manufacturing boring outcomes on purpose. This guide is about how that actually works, where the technology genuinely helps, and how to build an early-warning layer that your team believes rather than mutes.

The message up front: anomaly detection is not about predicting the future, it is about noticing the present faster and more consistently than a human watching dashboards ever could. It learns what normal looks like for an asset, then flags when reality drifts away from normal, early, while you still have time and options. The technology is the easy part. The hard part, and the part that decides whether the whole thing survives its first month, is trust.

1. Why early detection beats prediction and repair

Maintenance economics are unforgiving about timing. The same fault costs radically different amounts depending on how early you meet it. Catch a failing bearing while it is whispering in the vibration spectrum and you replace a cheap part during a planned window. Meet the same bearing after it has seized and you are replacing the shaft, the seal, the coupling, and paying for the unplanned downtime of everything that pump was feeding. The fault did not get more expensive because it got worse. It got more expensive because you met it later.

People often lump early detection together with prediction, and the two are related but genuinely different jobs. Prediction tries to answer a hard, forward-looking question: given the current trajectory, when will this asset fail and how much useful life remains? That is valuable and it is the subject of the predictive maintenance and failure prediction pillar, but it is also data-hungry and demands run-to-failure histories most sites do not have. Early detection asks a simpler and more immediately useful question: is this asset behaving abnormally right now, and is that deviation big enough that someone should look? You do not need to know when it will fail to benefit enormously from knowing that it has started to.

This is why I treat detection as the operational alerting layer that sits underneath everything else. Prediction is a horizon. Repair is the aftermath. Detection is the moment in between, the window where a cheap intervention is still possible, and it is the layer with the best return per dirham spent because it does not require a perfect model of failure, only a good picture of health. Preventive schedules still matter, and the preventive maintenance strategies pillar covers where fixed-interval work belongs, but preventive maintenance is blind between intervals. Anomaly detection is the thing that watches the gap.

2. What anomaly detection is (learning normal, flagging deviation)

Strip away the marketing and anomaly detection is a two-part idea. First, you build a model of normal behavior for an asset or a signal from data collected while it was healthy. Second, you continuously compare live behavior against that model of normal and raise a flag when the live behavior deviates beyond an expected range. That is the whole concept. Everything else is refinement of how you define normal and how you decide what counts as a meaningful deviation.

The reason this matters so much in maintenance is that it inverts the data requirement of classic failure prediction. To predict a specific failure you generally need labelled examples of that failure, and most organisations simply do not have many. Assets are expensive, they do not fail often on purpose, and when they do fail the event is rarely instrumented cleanly. Anomaly detection sidesteps that problem. It does not need to have seen the failure before. It only needs a good, representative picture of what healthy operation looks like, which every running asset produces continuously and for free.

Normal comes in a few flavors, and understanding them keeps you from being sold a black box. The simplest is a fixed threshold: bearing temperature above 80 degrees is abnormal, full stop. That is easy, transparent, and often the right tool, but it is crude because it ignores context. A more useful notion of normal is conditional. A motor drawing 40 amps is perfectly normal at full load and deeply abnormal at idle. So the better models learn normal as a relationship between variables, current as a function of load, discharge pressure as a function of speed, energy consumption as a function of outdoor temperature and time of day. When the observed value departs from what the relationship predicts, that residual is the anomaly. This is the practical heart of most industrial anomaly detection, and it is far more powerful than any single fixed limit because it understands context.

The third flavor is multivariate and temporal. Real assets are described by many signals at once, and a fault often shows up not as any single reading going out of range but as the pattern between readings changing shape. Vibration slightly up, temperature slightly up, current slightly up, none individually alarming, but together a signature that this specific machine has never produced while healthy. Detecting that kind of joint deviation is where machine learning earns its place, and it overlaps with the deeper pattern work covered in the deep learning for maintenance pattern recognition pillar. The distinction I keep in mind: pattern recognition is about discovering and naming the shapes of faults, while anomaly detection is about noticing, in real time, that today does not look like a healthy yesterday. This article stays firmly on the second job, the detection and alerting layer.

3. Detecting abnormal equipment behavior

Rotating equipment is where anomaly detection delivers most of its value, for the same reason it dominates condition monitoring generally: pumps, motors, fans, compressors and gearboxes fail through gradual, detectable mechanisms that leave signatures in vibration, temperature, current and acoustic data. Those signatures are the raw material anomaly detection feeds on.

Consider a straightforward example that recurs across every site I have worked. A centrifugal pump runs at a roughly steady duty. Over a period of weeks its motor current creeps upward by a few percent while its flow stays constant. No single reading trips an alarm. A technician glancing at the panel sees nothing wrong. But an anomaly model that has learned the normal relationship between load and current for this specific pump sees a residual growing steadily, current higher than the learned relationship predicts for the observed load, and raises a low-severity flag. The likely story is increasing mechanical resistance, a bearing beginning to drag or an impeller fouling. Caught here it is an inspection and a cheap fix. Missed, it continues to a trip.

The behaviors worth teaching a detection system to notice fall into a few recurring categories:

• Slow drift: a parameter trending gradually away from its learned baseline over days or weeks. This is the bread and butter of early warning, because drift is exactly what a human scanning dashboards fails to see. We are good at spotting sudden jumps and terrible at spotting slow creep.
• Changed relationships: two signals that normally move together starting to diverge. Discharge pressure that used to track pump speed now lagging it. This is often the earliest and most specific indicator of a developing mechanical problem.
• New oscillation or instability: a signal that used to be smooth beginning to hunt, cycle or become noisy. Control instability, cavitation and looseness announce themselves this way.
• Context-inappropriate readings: a value that is fine in absolute terms but wrong for the current operating state. High vibration at low speed, high temperature at low load. Absolute thresholds miss these entirely; conditional models catch them.
• Silence where there should be signal: an asset that should be modulating with demand sitting flat, or a sensor that has quietly stopped changing. Frozen signals are anomalies too, and they often indicate a failed sensor rather than a healthy asset, which matters enormously for trust.

That last point deserves emphasis. A large share of early anomaly flags in real deployments turn out to be instrumentation faults rather than asset faults. That is not a failure of the system, it is a feature, provided you have the discipline to distinguish the two. A detection layer that also polices the health of its own sensors is far more trustworthy than one that assumes every input is gospel.

4. Sensor anomaly detection in practice

In practice the signal you are watching is only as good as the sensor producing it, and any serious early-warning system spends real effort on the data before it spends any on the clever detection. This is the unglamorous middle of the pipeline that vendors skip in demos, and it is where most of the reliability of the whole system is won or lost.

The practical sequence for turning a raw sensor stream into a trustworthy anomaly flag looks like this:

Skip the validation and cleaning steps and you get an early-warning system that cries wolf constantly. A single dropped packet, a sensor glitch, a maintenance technician unplugging a probe, each produces a wild reading that a naive detector treats as a catastrophic anomaly. Nothing destroys confidence in a system faster than a screen full of critical alerts that all turn out to be a loose connector. The engineering effort that separates a trusted system from a muted one is disproportionately in this layer, not in the algorithm.

A few practical realities from deploying this on live plant:

• Sensors drift and fail more than assets do. A calibration drifting over months produces a slow anomaly that looks exactly like a developing asset fault. You need a way to tell the two apart, usually by cross-checking related sensors that should agree.
• Operating mode is everything. A model that learned normal for a machine running at full load will scream when the machine idles. Tag the operating mode and model each mode separately, or your false-positive rate is unmanageable.
• Startup and shutdown are not anomalies. Transients around start and stop look violently abnormal to a steady-state model. Either exclude them or model them explicitly, otherwise every morning startup generates a flurry of false alarms that train your team to ignore the system.
• Sampling rate must match the failure mode. Bearing defects live in high-frequency vibration and are invisible to a signal sampled once a minute. Energy drift is fine at coarse sampling. Match the rate to what you are trying to catch.

For the sensing and connectivity layer that makes any of this possible in a building or facility context, the smart building IoT and real-time monitoring pillar goes into the instrumentation and integration detail. Anomaly detection is the analytics that sits on top of that plumbing, and it is only ever as good as the plumbing beneath it.

5. Utility anomalies (consumption spikes and drops)

Utilities are a particularly rewarding place to apply anomaly detection because consumption is a summary signal. Water, electricity, gas and chilled-water flows aggregate the behavior of everything downstream, so an anomaly in consumption is often the first visible symptom of a fault you cannot see directly. You do not need a sensor on every pipe and panel to notice that something has changed; you need to watch the meters intelligently.

The two shapes that matter most are spikes and drops, and each tells a different story.

A consumption spike, usage jumping above what the learned pattern predicts for this hour, this day, this weather, points to waste or fault. A sudden overnight rise in water use when the building is empty is almost always a leak or a stuck valve. A step increase in electricity draw with no change in occupancy suggests a piece of plant running when it should be off, a stuck contactor, a control override left in place, or an efficiency loss where equipment now works harder for the same output. Spikes are the easier case because they are additive and obvious once you account for context.

A consumption drop is more interesting and more often missed. Usage falling below the expected pattern can mean an asset has stopped that should be running, a supply interruption, a failed pump, a sensor that has died and is now reporting zero. In metering, a drop to a suspiciously flat line is frequently a dead meter rather than genuinely reduced demand, and treating that flat line as good news is how you miss both the metering fault and whatever the meter was supposed to be watching. A good detection system flags the unexpected drop as loudly as the spike.

The core technique for utilities is baseline forecasting. You learn the normal consumption profile as a function of the drivers that actually move it, time of day, day of week, occupancy, and weather for anything thermal, then compare live consumption to that forecast and flag the residual. This is the same modeling backbone described in the utility and equipment performance forecasting pillar. The difference in emphasis is that forecasting cares about the predicted value while anomaly detection cares about the gap between prediction and reality. Same model, different question asked of it.

The insight that changes how teams use this: the most valuable anomaly is not the biggest one, it is the one that persists. A single spike is noise until it repeats. A small deviation that appears every night for a week is a fault developing on a schedule. Teach the system, and the team, to weight persistence and pattern over raw magnitude, and you catch the slow-burn problems that a magnitude-only alarm sails straight past.

6. Water leakage detection

Water leakage deserves its own treatment because it is where anomaly detection pays back visibly and quickly, and because it demonstrates the method cleanly. A leak is, by definition, water that flows when it should not, which is precisely a consumption anomaly against a learned baseline. The economics are compelling: undetected leaks waste a metered, billed resource continuously, cause secondary damage to structure and finishes, and in district or campus systems can run for months before anyone notices because nothing visibly breaks.

The most reliable signal for leak detection is minimum night flow. In most buildings and networks, water demand drops to a low baseline in the small hours when occupancy is minimal. That overnight minimum should be close to zero in a tight system. When the learned minimum night flow starts creeping upward, water is moving through the network at a time when almost nothing should be drawing it, and that is the classic signature of a developing leak. Watching the trend of the overnight minimum is one of the highest-value, lowest-complexity anomaly detections available, and it needs nothing more exotic than a flow meter and a model of what normal looks like at 3am.

Beyond night flow, several patterns distinguish a leak from legitimate demand:

• A continuous non-zero floor: demand that never returns fully to baseline, indicating a constant loss underneath the normal usage pattern.
• A step change with no operational cause: baseline consumption jumping to a new higher level and staying there, with no corresponding change in occupancy or process.
• Loss of the normal daily shape: usage that should peak and trough with occupancy flattening out as a large constant leak swamps the real demand signal.
• Pressure behaving oddly: in instrumented networks, pressure that struggles to hold overnight or drops in a zone is corroborating evidence that helps localize where the leak sits.

The honest scope note: consumption-based anomaly detection tells you reliably that a leak exists and roughly which metered zone it is in. It does not, on its own, tell you the leak is behind the third column on the second floor. Localization to a specific pipe still needs acoustic survey, zone isolation testing or physical inspection. The value of the detection layer is that it points the crew at the right zone quickly instead of leaving the leak to run for months, and it turns a vague suspicion into a work order with evidence attached. That is a very good return for a flow meter and a baseline model, and it is exactly the sort of unglamorous win that builds credibility for the whole early-warning program.

7. Electrical faults and abnormal loads

Electrical systems are rich territory for anomaly detection because electricity is measurable in fine detail and because many mechanical faults reveal themselves electrically before they reveal themselves any other way. The current a motor draws is a window into the mechanical load it is driving, so problems in the driven equipment often show up first as a change in the electrical signature.

The abnormal behaviors worth watching on the electrical side:

• Load creep: a motor or feeder drawing steadily more current for the same duty over time, indicating rising mechanical resistance, fouling, or degrading efficiency. This is the electrical twin of the pump example earlier and it is one of the most useful early signals available.
• Phase imbalance: current or voltage differing meaningfully across the three phases of a supply. Imbalance stresses motors, wastes energy and often precedes a winding or connection failure. A learned model of normal phase balance flags the drift early.
• Abnormal harmonics and waveform distortion: changes in the shape of the current waveform can indicate developing faults in motors, drives and power electronics well before a protective device trips.
• Thermal anomalies at connections: loose or corroded electrical connections heat up under load, and a temperature that climbs relative to its learned normal for the observed load is a classic precursor to an electrical failure or fire.
• Inrush and cycling changes: a change in startup current signature or an increase in how often a device cycles on and off can indicate control problems or a machine struggling against a developing mechanical issue.

The safety dimension raises the stakes here in a way it does not for most utility monitoring. An abnormal electrical load is not only an efficiency or reliability concern, it can be a fire and arc-flash risk. That changes how the alerting is designed. Some electrical anomalies genuinely warrant an immediate, high-priority alert that interrupts someone, because the consequence of waiting is not a bigger repair bill, it is a hazard. Getting this severity tiering right, distinguishing the connection quietly warming from the connection about to fail, is where an experienced reliability judgement has to be baked into the thresholds rather than left to a generic algorithm.

A practical caution: electrical signals are noisy and heavily dependent on operating context, and grid-side disturbances that have nothing to do with your asset can produce dramatic-looking anomalies. A voltage sag from a utility event will light up every panel you monitor. A detection layer that cannot distinguish a supply-side disturbance affecting everything from an asset-side fault affecting one machine will bury the real signal under correlated noise. Modeling normal per asset and correlating across the site to spot common-cause events is how you keep electrical anomaly detection from becoming a nuisance.

8. Catching the unexpected failure (novel faults with no prior example)

Here is the capability that makes anomaly detection genuinely different from every threshold and rule that came before it: it can catch a failure it has never seen. This is the single strongest argument for the approach, and it is worth being precise about how and why it works, because it is also where people either over-trust or under-appreciate the method.

A rule-based or threshold-based system can only catch the failures you anticipated when you wrote the rules. You set a high-temperature alarm because you knew overheating was a failure mode. But the failure mode you did not anticipate, the novel combination, the fault no one on your team has encountered on this asset, sails straight through because there is no rule watching for it. Anomaly detection inverts this. Because it defines abnormal as anything that deviates from learned normal, it does not need to have anticipated a specific fault. A failure that produces a genuinely new pattern, unusual, unlike anything the asset produced while healthy, gets flagged by virtue of being unusual, even though the system has no idea what it is.

This is the same principle that lets fraud detection catch a scam pattern it has never encountered, and it is enormously valuable in maintenance because the failures that hurt most are often the ones nobody planned for. The one-off. The strange interaction between two subsystems. The design weakness that only manifests under a rare operating combination. Threshold alarms are silent on these. A well-tuned anomaly detector notices that today is unlike any healthy yesterday and asks a human to look.

The honest limitation: catching the novel comes at a price, and the price is that the system cannot tell you what it found. It can only say this is abnormal, not this is a bearing fault. Diagnosis still requires a human with domain knowledge to interpret the flag. Worse, a genuinely novel operating condition that is perfectly benign, a new tenant, a changed process, a seasonal mode the model never learned, also looks abnormal and generates a flag. The system cannot distinguish a new fault from a new normal on its own. That is not a defect to be engineered away, it is an inherent property of learning normal from history, and it is precisely why the human-in-the-loop and the trust design in the next sections are not optional extras.

The way to hold this honestly with a management team is to frame anomaly detection as an attention router, not an oracle. It does not tell you what is wrong. It tells you where to point your limited expert attention, and it does so far more consistently and far earlier than a person scanning dashboards could. On a site with thousands of signals and a handful of engineers, directing scarce attention to the few things that have genuinely changed is a large and defensible win, even though every flag still needs a human to close.

9. Designing an early-warning system that avoids alarm fatigue

Everything above is achievable with current, well-understood technology. Whether it delivers value comes down almost entirely to one human factor: does the team trust the alerts enough to act on them, or have they learned to ignore them? Alarm fatigue is the single most common cause of death for early-warning programs, and it kills them quietly. The system keeps working, the alerts keep firing, and everyone stops looking. A muted early-warning system is worse than none, because it created cost and provides a false sense of coverage.

Alarm fatigue is not caused by too many faults. It is caused by too many alerts that turn out not to matter. Every false positive, every flag that a technician investigates and finds nothing, teaches the team that the next flag is probably also nothing. Do that enough times and the most rational response is to stop checking. The entire discipline of early-warning design is really the discipline of keeping the signal-to-noise ratio high enough that acting on an alert stays worthwhile.

The design principles that keep an early-warning system trusted:

• Tier severity honestly. Not every deviation deserves the same alert. A low-severity flag that lands in a daily digest, a medium flag that pings a channel, a high flag that interrupts someone, and only genuine emergencies that phone a human. Collapsing everything into one alert level guarantees fatigue.
• Suppress the known and the transient. Startups, planned mode changes, maintenance activities and known benign conditions should not generate alerts. If the team knows the pump was deliberately run, an alarm about it running erodes trust in every other alarm.
• Require persistence before escalating. A single sample deviating is noise. A deviation that persists across a defined window is signal. Debouncing on time removes a huge fraction of nuisance flags at almost no cost in missed real faults.
• Group related alerts. One root cause often trips many signals. A supply event that lights up forty panels should surface as one incident, not forty alerts. Correlation and grouping keep a single problem from feeling like a flood.
• Give every alert context and a next step. An alert that says "anomaly on AHU-3" with no trend, no baseline and no suggested action is a burden. An alert that shows the deviation, the recent trend and a recommended check is something a technician can act on in seconds.
• Close the feedback loop on false positives. Let the team mark a flag as a genuine issue or a false alarm, and feed that back into tuning. A system that visibly gets quieter and sharper over time earns trust; one that never learns from being wrong loses it.

The judgement that underpins all of this is a deliberate choice about where to sit on the trade-off between missing real faults and raising false alarms. Tune the system too sensitively and you drown the team in noise until they mute it. Tune it too conservatively and it stays quiet while faults develop, which erodes trust in the other direction when a failure the system should have caught slips through. There is no universally correct setting. The right point depends on the consequence of the asset, the cost of investigation, and the team's tolerance, and it should be revisited as the program matures. Starting slightly conservative and tightening as trust builds is usually wiser than starting sensitive and burning credibility in the first week.

10. Acting on alerts: closing the loop into the CMMS

An anomaly flag that lands in an email or a standalone dashboard, disconnected from the maintenance system of record, will be ignored within weeks no matter how accurate it is. This is the same integration gap that quietly kills predictive maintenance programs, and it applies with equal force to detection. The value of an early warning is only realised when it becomes an action that gets scheduled, executed, closed out, and recorded where the rest of the work lives.

The loop that a mature early-warning system closes:

The two ends of that loop are the ones organisations neglect. At the front, an anomaly should be able to raise a work order in the same CMMS or EAM where technicians already work, carrying the evidence with it, the trend chart, the affected signals, the severity, so the person picking it up does not have to go hunting for context. At the back, the outcome of the work order, was it a real fault, what was the cause, what was done, must flow back to the detection layer. That feedback is what turns a static detector into one that gets sharper, because every confirmed fault and every false alarm is a labelled example that improves the next judgement.

Closing that loop also demands clean failure coding on the way out, because a work order closed with a comment of "checked, ok" teaches the system nothing. The Problem-Cause-Action discipline covered in the failure codes pillar is what makes the returned outcome usable as feedback. Without it you have a detection system that fires and forgets, and it will neither improve nor build the track record that justifies its existence. The organisations that get real value from anomaly detection are the ones that treat the CMMS integration and the failure coding as first-class parts of the program rather than an afterthought bolted on once the sensors are already installed.

11. The honest limits: false positives, thresholds and trust

It would be dishonest to present anomaly detection as a solved problem, so here are the limits I make sure every client understands before they commit, because knowing them up front is what separates a program that survives from one that gets quietly abandoned.

False positives are unavoidable, the only question is the rate. Any system sensitive enough to catch real faults early will occasionally flag things that turn out to be nothing. That is inherent, not a bug to be eliminated. The goal is not zero false positives, it is a false-positive rate low enough that investigating a flag remains worthwhile. Chasing zero false positives inevitably means missing real faults, because the two errors trade off directly against each other.

Thresholds are judgement calls dressed as numbers. Every deviation limit encodes a decision about how much abnormality is worth someone's attention, and that decision depends on the asset, the consequence and the team. There is no objectively correct threshold handed down by the data. Setting them well requires domain knowledge, and setting them badly is the fastest route to either fatigue or missed faults. Anyone who tells you the algorithm sets the thresholds automatically and optimally is selling you the confidence they do not actually have.

Normal changes, and models go stale. Assets age, processes change, seasons turn, tenants move in and out. A model of normal learned last year may be wrong this year, and a stale model either misses new faults or flags the new normal as abnormal. Early-warning systems need periodic retraining and a human who notices when the definition of normal has legitimately shifted. This is ongoing work, not a one-time setup, and budgeting for it honestly is part of doing the thing properly.

Detection is not diagnosis. The system tells you something is abnormal, not what is wrong or what to do about it. The expertise to interpret a flag, decide whether it is real, and choose the intervention still lives with people. Anomaly detection makes good engineers more effective by pointing their attention accurately. It does not replace them, and any program sold on the premise that it will is heading for the disappointed-eighteen-months-later story.

Trust is earned slowly and lost quickly. This is the human truth that outweighs all the technical ones. A team will extend trust to an early-warning system cautiously, one accurate alert at a time, and withdraw it all at once after a run of false alarms or one embarrassing miss. Protecting that trust, by starting conservative, tuning honestly, closing the loop and being straight about what the system can and cannot do, matters more to the program's survival than any choice of algorithm. The best detector in the world delivers nothing if the people it serves have learned to mute it.

Final thoughts

Anomaly detection is the most immediately useful piece of the applied-AI toolkit for maintenance and utilities, precisely because it asks the easy question rather than the hard one. It does not try to predict the future or diagnose the fault. It learns what normal looks like and tells you, early and consistently, when reality has drifted away from it. On rotating equipment, on utility meters, on water networks and on electrical systems, that early flag is the difference between a cheap planned fix and an expensive unplanned failure, and it works even for faults no one anticipated, because abnormal is defined by deviation rather than by a rule someone had to write in advance.

But the technology is the part you can buy, and it is not the part that decides whether this succeeds. What decides it is whether the people who receive the alerts trust them enough to act. Get the data quality right so the flags are real. Tier the severity so the important ones stand out. Suppress the transient and the known so the noise stays low. Close the loop into the CMMS so an alert becomes a work order and the outcome sharpens the next judgement. Be honest that detection is not diagnosis and that a human still has to decide. Do those things and an early-warning system becomes a quiet, trusted part of how the operation runs. Skip them and you build one more dashboard that everyone learned to ignore, which is the most expensive kind of monitoring there is, because it cost real money and changed nothing.

Related reading: Predictive maintenance and failure prediction, Deep learning for maintenance pattern recognition, Utility and equipment performance forecasting, Smart building IoT and real-time monitoring, Preventive maintenance strategies.