Photo by TECNIC Bioprocess Solutions on Unsplash.
Condition based maintenance (CBM) is a maintenance policy that triggers work only when equipment condition data says it’s needed — not on a fixed calendar, and not after something breaks. A vibration reading crosses a threshold, a bearing temperature climbs past its baseline, a compressor’s current draw drifts out of its normal band — and that’s what schedules the work order, not the 90-day calendar reminder in your CMMS.
CBM sits between two ideas that get used almost interchangeably, and shouldn’t be. Condition monitoring is the sensing and data layer — the vibration sensors, current transformers, and thermal probes that produce the readings. Predictive maintenance is the modeling layer — the statistics or machine learning that turns those readings into a forecast (“this bearing has roughly three weeks of useful life left”). Condition based maintenance is neither of those. It’s the policy layer: the rule that says work happens when a threshold is crossed, whether that threshold comes from a simple alarm limit or a predictive model’s output. You can run CBM with nothing more sophisticated than a spreadsheet and a threshold — you don’t need machine learning to do it.
It’s also distinct from fault detection and diagnostics, which flags a specific fault once it has already appeared in the data. FDD tells you what’s wrong; condition based maintenance is the policy that decides what happens next.
Condition based maintenance vs. predictive maintenance vs. preventive maintenance
The three strategies solve the same problem — deciding when to intervene — with different amounts of data and different risk profiles. Preventive maintenance is the default most buildings still run; predictive maintenance is the most data-intensive; condition based maintenance sits in between, and for a lot of building equipment, it’s the better trade-off.
Strategy | Trigger | Data required | Lead time before failure | Best fit |
|---|---|---|---|---|
Reactive (run-to-failure) | Equipment fails | None | None | Low-value, redundant equipment |
Preventive | Fixed calendar or runtime interval | Manufacturer schedule | N/A (arbitrary) | Equipment with well-known wear curves |
Condition based maintenance | Sensor reading crosses a threshold | Live condition data (vibration, temperature, current, etc.) | Days to weeks | Critical equipment with irregular wear |
Predictive maintenance | Model forecasts remaining useful life | Condition data plus historical failure data and a model | Weeks to months | High-value assets where downtime cost justifies modeling |
Predictive maintenance needs failure history to train against, and most buildings don’t have enough of it for anything but their highest-value assets. Condition based maintenance doesn’t: a threshold you can defend with an engineer’s judgment is enough to start.
Predictive maintenance condition monitoring: where the two overlap
In practice, most mature programs don’t pick one strategy and stop — they layer condition based maintenance under predictive maintenance condition monitoring once they have enough sensor history to justify the extra modeling work. The condition monitoring layer supplies the raw signal: vibration spectra, bearing temperature trends, motor current signatures. A simple condition based maintenance policy acts on that signal directly — cross the threshold, open the work order. A predictive maintenance condition monitoring program goes one step further and feeds the same signal into a model that estimates remaining useful life, so the work order carries a timeframe (“replace within 15 days”) instead of just a flag.
Neither replaces the other. CBM is what most teams should run first, because it doesn’t require a failure-history dataset. Predictive modeling is the upgrade you add once the condition data has been flowing long enough to train against.
How condition based maintenance works
A CBM program has four moving parts, and building teams that skip straight to buying sensors usually get stuck at step three.
Instrument the asset — vibration, temperature, current, oil analysis, or pressure sensors, chosen for the failure modes that actually matter for that equipment type.
Set a baseline and a threshold — what does “normal” look like for this specific unit, and how far from normal triggers action? Manufacturer specs are a starting point, not the final answer; a chiller that’s run hot since installation has a different “normal” than the spec sheet.
Route the alert to a work order automatically — a threshold breach that lands in an inbox nobody reads isn’t condition based maintenance, it’s condition monitoring with extra steps.
Close the loop — track whether the intervention actually prevented a failure, and tune the threshold. Too sensitive, and technicians start ignoring alerts; too loose, and you’re back to run-to-failure.
When condition based maintenance is the right call — and when it isn’t
CBM earns its keep on equipment where failure is expensive or disruptive, but wear is irregular enough that a fixed calendar either wastes maintenance budget or misses failures. Chillers, cooling towers, large pumps, and rooftop units are the classic building candidates — their duty cycles vary enough with weather and occupancy that a calendar-based interval is either too conservative (replacing parts that had life left) or too aggressive (missing a unit that’s been running harder than average).
It’s a worse fit for equipment that’s cheap to replace, redundant, or fails in ways that don’t show up as a gradual trend — a light fixture or a low-value control valve doesn’t justify the sensor and monitoring cost. And it’s a worse fit for teams without the operational discipline to act on alerts; a threshold that nobody responds to for three weeks doesn’t save you anything over the calendar you replaced.
Building a condition based maintenance program that sticks
Most CBM rollouts fail on process, not sensors. The build order that works: start with the 10–20 assets where unplanned downtime is most expensive (mechanical rooms, not individual VAV boxes), instrument only those, and prove the threshold-to-work-order loop closes reliably before expanding. A fault detection and diagnostics layer is worth adding once the basic CBM loop is running — FDD catches faults condition monitoring alone can miss, like a stuck damper or a miscalibrated sensor, and routes them into the same work-order pipeline.
Condition based maintenance ROI: how to justify the investment
The business case for CBM is rarely "we’ll spend less on maintenance" — in the first year, instrumentation and program setup often cost more than the calendar-based routine it replaces. The case is avoided downtime and avoided over-maintenance, and both need a number attached before anyone signs off on sensors.
Avoided unplanned downtime — price the last two or three unplanned failures on the equipment you’re targeting: lost tenant hours, emergency callout premiums, expedited parts shipping. CBM doesn’t eliminate failures, but it turns most of them into planned repairs with parts ordered in advance.
Avoided over-maintenance — a calendar-based PM schedule replaces parts and drains oil on a fixed interval regardless of actual wear. Pulling the maintenance log for equipment you’re about to instrument usually shows a meaningful share of that spend was unnecessary.
Extended asset life — catching a bearing running hot before it seizes protects the motor around it, not just the bearing. That avoided capital replacement is often the largest line item, and the easiest one to underestimate.
Most teams start the ROI case on a handful of assets — the ones already showing up repeatedly in the unplanned-downtime log — rather than trying to model a portfolio-wide business case before a single sensor is installed.
Common condition based maintenance mistakes
Instrumenting everything at once — sensors on low-value equipment generate alert volume without proportional payoff, and bury the alerts that actually matter under noise.
Using manufacturer thresholds without adjusting them — a spec-sheet vibration limit assumes a specific installation and duty cycle; an asset that’s run harder or softer than that assumption needs its own baseline.
Treating an alert as the end of the workflow — if a threshold breach doesn’t automatically create a work order with a technician assigned, it’s condition monitoring, not condition based maintenance.
Never revisiting thresholds — a threshold set once and never tuned drifts out of relevance as equipment ages; what counted as “normal” in year one of an asset’s life is not “normal” in year eight.
Condition based maintenance software: what it actually needs to do
You don’t need a full predictive maintenance platform to run condition based maintenance — you need three things: a way to ingest sensor or BMS data, configurable thresholds per asset, and a work-order integration so a breach turns into a dispatched technician without a human in the loop. Some CMMS platforms bolt this on; some building analytics platforms do it natively across every piece of equipment reading into the BMS, without per-asset configuration. We’ve compared the leading condition based maintenance software options — including where a narrow CMMS add-on is enough and where you need a platform built for it — separately, since the shortlist depends heavily on how many buildings and BMS vendors you’re consolidating.
FAQ
What is condition based maintenance?
A maintenance policy that triggers work based on real-time equipment condition data — a threshold breach in vibration, temperature, or current — rather than a fixed calendar interval or waiting for failure.
Condition based maintenance vs. predictive maintenance — what’s the difference?
Condition based maintenance acts directly on a threshold breach in condition data. Predictive maintenance adds a statistical or machine-learning model on top of that same data to forecast a failure window in advance. CBM is simpler to start and doesn’t require failure history; predictive maintenance is more precise but needs more data to train against.
What sensors does condition based maintenance need?
It depends on the failure mode you’re watching for — vibration and temperature sensors for rotating equipment like pumps and motors, current sensors for electrical loads, and oil analysis for gearboxes and large compressors. Most building teams start with what their BMS already reads before adding dedicated sensors.
Is condition based maintenance the same as condition monitoring?
No. Condition monitoring is the sensing and data layer. Condition based maintenance is the policy that decides what happens when that data crosses a threshold — condition monitoring can run without CBM attached to it, but CBM can’t run without some form of condition monitoring feeding it.
What condition based maintenance software should I use?
It depends on whether you’re managing a single building or a portfolio across multiple BMS vendors. See our comparison of the leading condition based maintenance software platforms for a breakdown.
How much does a condition based maintenance program cost to start?
Cost scales with how much you already read into your BMS versus how many dedicated sensors you need to add. Teams that start with the 10–20 assets already causing the most unplanned downtime, and lean on existing BMS points before buying new hardware, get a working program live for a fraction of what instrumenting an entire portfolio up front would cost.
FrostLogic Explore brings sensor intelligence, scenario simulation, and grounded-inference AI to commercial and industrial buildings. Learn more about Sensor Intelligence or talk it through with us.
Curious how this would look on your building?
What's your building not telling you?
Tell us what you're trying to figure out: energy drift, a BMS you don't trust, compliance you're chasing. We listen first, then tell you straight whether Explore helps. 30 or 60 minutes, your pick. No commitment either way.
