Predictive Maintenance for Buildings: A Practical Guide

Predictive maintenance for commercial buildings: from sensor data to fewer breakdowns

A chiller does not usually fail without warning. The efficiency curve drifts for weeks, the approach temperature creeps, the amp draw climbs a little each cycle. The compressor that seizes on a Friday afternoon had been telling you for most of a month. The data was there. Nobody was reading it.

Closing that gap, between what the equipment is signalling and what anyone actually sees, is the whole point of predictive maintenance. The promise is simple. Catch the failure while it is still cheap to fix, on a schedule you choose, instead of at 4pm on the hottest day of the year when the tenants are calling. The execution is where it gets interesting, and where most projects come unstuck.

This is a practical guide to predictive maintenance for buildings: what it is, what it actually needs, which failures you can see coming from the sensors you already have, and why so many programmes stall before they pay off.

Reactive, preventive, predictive: three ways to run a building

Every maintenance strategy is one of three things, and most estates run a messy blend of all three.

Reactive is run-to-failure. You fix it when it breaks. It feels cheap because you defer the cost, but the deferred cost is the worst kind: emergency call-outs at overtime rates, collateral damage to connected plant, and downtime that lands at the least convenient moment. Studies of industrial estates put reactive-heavy sites at more than three times the downtime of proactive ones. The bill always arrives; reactive just lets it compound first.

Preventive is calendar-based. You service the AHU every quarter and replace the belt every twelve months whether it needs it or not. This is better than waiting for the break, and it is where most well-run buildings sit. The waste is in the calendar itself: you replace parts with life left in them, you send a technician to plant that is running fine, and a fixed schedule still misses the failure that decides to happen in month seven.

Predictive is condition-based. You watch the actual state of the equipment and act when the data says a failure is developing, not on a fixed date and not after the breakdown. Done well, it is the cheapest of the three over an asset’s life. The figures from operators who have made the shift are consistent: predictive maintenance tends to cut maintenance spend by around a fifth against a preventive baseline, and unplanned downtime by somewhere between 30 and 50 percent. McKinsey’s number for downtime reduction sits squarely in that range. The catch is that those figures describe programmes that worked, and plenty do not get there.

The reason predictive maintenance is the most-cited planned AI investment for facility teams going into 2026 is that the savings are real and the technology has caught up. The reason most buildings still run reactive-to-preventive is that the gap between buying a predictive tool and getting value from one is wider than the brochures admit.

What predictive maintenance actually needs

Strip away the marketing and a predictive-maintenance system is a chain of four links. Sensors that measure the equipment. A pipeline that moves the data somewhere usable. Models that judge whether what they are seeing is normal. And the link everyone underweights: a work order that lands in front of a person who acts on it.

The first three links are mostly solved. Commercial buildings are already instrumented far more heavily than their operators realise. A typical mid-sized estate generates thousands of data points an hour from its building management system: supply and return temperatures, valve positions, fan speeds, pressures, power draw, runtime hours. The physics of failure is well understood, too. Most developing faults leave a signature in that data days, sometimes weeks, before the equipment actually stops. Bearing wear shows up as a vibration and current-draw drift a couple of weeks out. A belt glazes and changes its signature before it snaps. A motor’s casing temperature trends up well ahead of the thermal trip.

So the prediction itself is rarely the hard part. The hard part is the last link. A forecast that a fan bearing will fail in two weeks is worth nothing if it surfaces as one more line in an alarm log that nobody opens, or if it arrives without enough context for a technician to know what to do. The difference between a predictive-maintenance programme that works and one that quietly dies is almost never the quality of the model. It is whether the prediction becomes an action someone takes. Most vendors sell you the model. The model was never the problem.

The failure modes you can already see coming

You do not need a forest of new sensors to start. Most of the failures that hurt are visible in data a standard BMS already collects. A few of the high-value ones:

Bearing and vibration drift. Fan and pump bearings degrade gradually, and the degradation shows up as rising vibration and a creeping change in motor current long before the bearing seizes. This is the canonical predictive-maintenance win — a slow, readable decline with a clear intervention point.

Chiller efficiency decline. A chiller losing efficiency, whether from fouling condensers, a refrigerant problem, or a failing compressor, broadcasts it through kW/ton, approach temperatures, and discharge pressures. Tracking efficiency against the expected curve for current conditions catches a problem months before it becomes a breakdown, and the energy waste in between is its own line item.

AHU and VAV faults. Stuck dampers, leaking valves, simultaneous heating and cooling, sensors that have drifted out of calibration. These rarely cause a dramatic failure, which is exactly why they persist for months — burning energy and wrecking comfort while the building keeps running. They are detectable the moment you compare what the unit is doing against what it should be doing.

Filter loading. Pressure drop across a filter tells you when it is actually loaded, rather than when the calendar says to change it. A small saving per unit, but it scales across a portfolio and it is nearly free to monitor.

Pump cavitation and flow anomalies. Cavitation, blockages, and failing impellers shift the relationship between pressure, flow, and power. Watch those together and the fault is obvious before the pump is damaged.

The pattern across all of them: the signal is in data you already have, and the failure develops slowly enough to act on. That is what makes building plant such good ground for prediction. The question is never really “can we see it.” It is “will anyone do anything when we do.”

Why most predictive-maintenance projects stall

Here is the uncomfortable part. Plenty of buildings have bought predictive-maintenance tools and gone back to running reactive within a year. The technology worked. The programme failed. Almost always for the same reason: alarm fatigue.

A system tuned to miss nothing flags everything. Static thresholds fire whenever a reading crosses a line, regardless of whether that value is unusual for that asset in those conditions. Models that have not learned what normal looks like for a specific chiller throw alerts at it anyway. Every anomaly arrives with the same urgency, so a drifting sensor reads as loud as an imminent compressor failure. A maintenance crew can absorb a few false positives. Fed a dozen a day, they start ignoring the lot, and the one alert that mattered gets ignored with the rest. Each false dispatch costs real time too, an hour or more of wrench time chasing a ghost, which is exactly the cost the programme was meant to remove.

Once a team stops trusting the alerts, the programme is dead even if the software keeps running perfectly. Rebuilding that trust takes months, and most teams just revert to the calendar in the meantime.

The fix is not a better-tuned threshold. It is a different output. Instead of an alarm stream, the system should produce a short, ranked list: the handful of issues genuinely worth a technician’s time this week, each with a severity, the reason it was flagged, and a proposed next step. Prioritisation is the product. A model that surfaces three real problems in priority order beats one that catches all forty and buries them. This is the whole idea behind a prioritised decision queue rather than a dashboard of blinking lights. The building tells you what needs you, in order, and you work down the list until you run out of time for the week.

Predictive maintenance, anomaly detection, FDD: sorting the vocabulary

These three terms get used interchangeably, and the slippage causes confusion in buying conversations. They are related but not the same.

Anomaly detection answers one question: is this reading unusual? It flags that a value or pattern departs from normal. It does not, on its own, tell you why or what to do. It is the underlying sensing layer. (We go deep on the methods in how AI anomaly detection works in building sensor data.)

Fault detection and diagnostics (FDD) goes a step further. It does not just flag that something is unusual; it names the fault in operational terms (“this AHU is heating and cooling at the same time”) and points at a probable cause. FDD is about explaining faults in language an operator can act on.

Predictive maintenance is the forward-looking discipline that uses both. It is concerned with what will fail and when, so you can intervene before it does. Anomaly detection and FDD tell you about the present and the recent past; predictive maintenance extends that into a forecast and ties it to a maintenance decision. Forecasting is what turns “this is drifting” into “this will cross the line in twelve days.”

In practice you want all three working together: detection to see the signal, diagnostics to explain it, prediction to put a clock on it. A tool that only does one and claims to do all three is the source of a lot of disappointed programmes.

Getting started without a rip-and-replace

The biggest myth about predictive maintenance is that it requires new hardware and a new control system. For most commercial buildings, it does not. The sensors are already in the plant and the BMS is already reading them. What is missing is the analysis layer on top.

The low-risk way in is read-only. A sensor-intelligence layer ingests data from the BMS you already run, across vendors and protocols, without touching control logic and without a forklift upgrade. Nothing about how the building is controlled changes. You are adding a layer that reads the existing signals, learns what normal looks like for each asset, and produces the ranked queue. If it is wrong, it is wrong about what to look at, not about how the plant runs. That asymmetry is what makes it safe to start.

A sensible first move is to point it at the assets where failure hurts most: the central chillers, the big AHUs, the critical pumps. Prove the queue catches real problems before they escalate, then widen from there. The same approach that works on a building’s HVAC plant carries over to heavier process equipment; we cover the industrial side in predictive maintenance for manufacturing.

A chiller does not fail without warning. Neither does most building plant. Predictive maintenance is really just the discipline of reading that warning and acting on it before the Friday afternoon. Your building has been generating the signal all along. The harder question is whether anyone is set up to act on it.

See what your equipment data predicts — request a 20-minute demo. Senior engineer on the call.