Predictive Maintenance

Condition-Based Maintenance: When Does It Actually Pay Off

Condition based maintenance only pays when the warning window beats your response time. Here is the maths that decides it, and where sensors are wasted money.

SP
Shane Price
AssetOS
·August 17, 2026·9 min read
assetos cli — cbm screen
visitor@assetos.io:~$ assetos cbm --assess critical
14 critical assets scored
6 clear the response-time test
·8 stay on time-based ppm
visitor@assetos.io:~$

Condition-Based Maintenance: When Does It Actually Pay Off

A sensor supplier will happily quote you for monitoring every rotating asset on site. The brochure will say condition-based maintenance cuts downtime by 30–50%, and it can. What the brochure won't tell you is that the number assumes something you probably don't have: the ability to act on the warning before the warning expires.

That's the whole question. Condition-based maintenance isn't a technology decision, it's a logistics one. The kit that detects a failing bearing is cheap and boringly reliable now. The expensive part is having spares, labour and a production slot ready inside the window the sensor buys you. Get that wrong and you've paid for an alarm clock that goes off while you're stuck in traffic.

Here's how to work out which of your assets clear the bar, and which are being sold monitoring they can't use.

What Condition-Based Maintenance Actually Is

Condition-based maintenance (CBM) triggers work when a measured condition crosses a threshold. Vibration exceeds 4.5 mm/s. Bearing temperature runs 15°C above baseline. Oil particulate count hits ISO 18/16/13. The asset tells you it needs attention, and only then does anyone touch it.

That threshold trigger is what separates CBM from the two things it gets confused with.

It isn't preventive maintenance. A time-based schedule services the pump every 90 days regardless of how the pump is doing. CBM services it when the pump says so. Both are proactive; only one of them stops replacing components that still had life left.

It isn't predictive maintenance either, despite the terms being used interchangeably by nearly everyone selling either. CBM is a threshold: you cross a line, work is raised. Predictive maintenance (PdM) is a forecast: a model consumes the same condition data and estimates remaining useful life — "this bearing has roughly six weeks." CBM is a smoke alarm. PdM is a weather forecast. The distinction matters commercially, because CBM is achievable with a £300 sensor and a sensible threshold, whereas a forecast that anyone trusts needs failure history most SMB sites simply haven't collected yet.

If you're still deciding at the strategy level rather than the asset level, the preventive vs predictive maintenance comparison covers the wider trade-off. This piece is the asset-by-asset test underneath it.

Gate One: The Failure Has to Announce Itself

Every CBM case has to clear two gates, and most fail the second one. But start with the first, because it's the one physics decides for you.

You need a P-F interval — the gap between the point a failure becomes detectable (P) and the point the asset actually fails (F). That interval is a property of the failure mode, not of your budget. No amount of sensor spend creates warning where the physics doesn't produce any.

TechniqueWhat it catchesTypical P-F interval
Vibration analysisBearing and rotor defects, imbalance1–9 months
Oil analysisGear and bearing wear, contamination2–6 months
Acoustic emissionCrack propagation, leaksUp to 12 months
ThermographyLoose connections, overload, insulationWeeks to months
Motor current signatureRotor bar and winding faultsWeeks to months

Now the assets that fail the gate outright: a relay that switches perfectly until the instant it doesn't. A fuse. A control board. A hose that bursts. These have no meaningful degradation curve, so there's nothing to monitor. They belong on time-based replacement with spares held, and any quote that includes sensors for them is selling you comfort.

Roughly speaking, if you can't name the physical parameter that drifts before failure and the instrument that reads it, the asset fails gate one.

Gate Two: The Warning Has to Beat Your Response Time

This is the one that gets skipped, and it's where CBM programmes quietly die.

A P-F interval is only useful if it's longer than the time it takes you to do something. Write it out:

Usable warning = P-F interval − (detection lag + decision time + parts lead time + access window)

Every one of those subtractions is real:

  • Detection lag. A monthly vibration route detects on average half a month late. A permanently-mounted sensor detects in near real time. This is the main thing continuous monitoring buys you over a clipboard, and it's worth quantifying before you pay for it.
  • Decision time. How long between the alert landing and someone with authority approving the work. On most sites this is days, not hours, and nobody measures it.
  • Parts lead time. The killer. A six-week lead time on a gearbox eats a six-week warning entirely.
  • Access window. When can you actually take the asset out? If the line only stops at Christmas, your usable warning is bounded by the shutdown calendar, not by the sensor.

If that subtraction comes out negative, CBM on that asset gives you nothing but advance notice of a failure you'll take anyway. Which is worth something — you can pre-stage a response — but it isn't worth a monitoring programme, and it certainly isn't worth the 30–50% downtime reduction in the business case.

A worked example

Two assets on the same site, both critical, both with textbook degradation curves:

Line 2 gearboxChilled water pump
P-F interval (vibration)4 months4 months
Detection lag (continuous sensor)~0~0
Decision time1 week1 week
Parts lead time14 weeks (bespoke)3 days (stocked)
Access windowAny weekendAny weekend
Usable warning−1 week~15 weeks
VerdictHold a spare insteadFit the sensor

Identical failure physics, opposite answers. The gearbox doesn't need a sensor, it needs a spare gearbox on the shelf — and once you're holding the spare, the monitoring adds far less. The pump clears the gate comfortably, and at that point the sensor cost is trivial against an hour of lost production.

That's the analysis, and it takes about ten minutes per asset. Do it before you get a quote, not after.

Where Sensors Are Wasted Money

Two patterns cost operators more than anything else I've seen.

Monitoring the long tail. Criticality analysis on almost every site puts 10–20% of assets behind most of the downtime risk. Instrumenting the other 80% produces data volume, dashboard clutter, and alert fatigue — and alert fatigue is how the genuinely urgent alarm gets dismissed. Rank the assets first; the riskiest assets in your business are a much shorter list than the sales deck assumes.

Buying continuous monitoring where a route would do. Manual CBM is still CBM. A technician with a handheld vibration pen and a thermal camera walking a monthly route is condition-based maintenance, and on assets with a four-month P-F interval the extra detection lag is immaterial. Continuous sensors earn their money on short P-F intervals and on assets that are awkward, unsafe or expensive to reach. For a mid-sized site, a disciplined route covers most of the value at a fraction of the cost — and it builds the failure history you'll need later if you ever do want a predictive model.

The third pattern is subtler: running CBM as a parallel system. If a sensor alert raises a ticket in the monitoring vendor's portal while planned work lives in your preventive maintenance software, you now have two queues, two priorities, and no single view of what's outstanding. A condition alert should raise the same work order a PPM does, in the same place, assigned the same way.

The Sequence That Works

CBM sits on top of a working preventive programme. It doesn't replace one, and it can't rescue a broken one.

  1. Get every asset on a baseline schedule first. Time-or-usage intervals across the register. If you don't have this, start with a PPM schedule builder and worry about sensors next year.
  2. Rank by consequence of failure. Downtime cost per hour × likelihood. Take the top 10–20%.
  3. Apply gate one. Does the failure mode degrade detectably? Cross off the ones that don't.
  4. Apply gate two. Usable warning after lead times and access windows. Cross off the negatives.
  5. Choose route vs continuous per surviving asset. Short P-F interval or hard access → continuous. Otherwise start with a route.
  6. Set thresholds from your own baselines, not the manufacturer's. Measure the asset healthy for a few weeks, then set the alarm point above normal variation. Thresholds copied from a datasheet are the most common source of false alarms.
  7. Route every alert into the normal work-order queue. One queue, always.
  8. Review at 90 days. Count alerts, false positives, and catches. If nobody acted on an alert, find out why before you add more sensors.

Track the same numbers you'd use for any maintenance change — MTBF, MTTR and the rest — from before you start. A CBM programme with no pre-baseline can't prove it worked, which is how good programmes get cut in the next budget round.

The Honest Summary

Condition-based maintenance pays off on a narrow, identifiable slice of your assets: high consequence of failure, a failure mode that degrades detectably, and a supply chain fast enough to use the warning. On that slice it's excellent, and payback on a critical asset with real downtime cost is measured in months.

Everywhere else, a well-run preventive schedule and a spare on the shelf beat a sensor. That's not a fashionable position, but it's the one that survives contact with a parts lead time.

AssetOS keeps condition-triggered work and time-based PPM in the same work-order queue, against the same asset register, so a threshold alert and a routine service are planned by the same people in the same place. If you want a second opinion on which of your assets actually clear both gates, book a call and we'll go through the list.

Share
SP

Shane Price

AssetOS

Writing about maintenance management, CMMS implementation, and the real challenges operations teams face.

Related reading

We use cookies to analyse site traffic and improve your experience. Read our cookie policy