From 5 to 500: Why Condition Monitoring Programs Fail at Scale
Condition monitoring pilots often succeed on a handful of assets and stall at plant scale. The fix is architectural: criticality tiers, the right modality per failure mode, integration, alert management, and staffing.
The pilot story is familiar. A reliability engineer instruments a handful of critical pumps or compressors, reviews every spectrum personally, catches a developing bearing fault weeks early, and presents the avoided failure to leadership. Budget for a plant-wide rollout follows.
A year or so later, the program has quietly stopped growing. The original assets are still monitored. Most of the expansion list never got past the purchase order. Nothing dramatic failed. The conditions that made the pilot work simply did not scale.
This article explains why, and gives a playbook for brownfield plants that want to go from a few monitored assets to hundreds without drowning in data, alerts, and integration work.
Your pilot worked. That is the problem.
A pilot succeeds for reasons that are hard to reproduce. One motivated analyst knows every machine's operating profile, reviews every alert by hand, and walks the floor to confirm findings. At five assets, that is feasible. At two hundred, the same analyst cannot review every spectrum, and the hand-tuning that made alerts trustworthy disappears.
The U.S. Department of Energy's O&M Best Practices Guide (Release 3.0) is blunt about this. It advises that predictive maintenance equipment should not be purchased for in-house use without a serious commitment to proper implementation, operator training, and equipment monitoring and repair, and that a site without that commitment may be better served by contracting the service [1]. Scaling is not a sensor purchase. It is an operating model.
The payoff is worth getting right. The DOE guide cites independent surveys reporting average reductions of 25% to 30% in maintenance costs and 35% to 45% in downtime from a functional predictive maintenance program [1], and NIST associated predictive maintenance with 15% less downtime in its study of U.S. manufacturers [2].
Key Statistics
35% to 45% [1]
Average downtime reduction from a functional predictive program, per surveys cited by the DOE O&M guide
15% [2]
Less downtime associated with predictive maintenance in NIST's study of U.S. manufacturers
45% to 55% [3]
Predictive share of maintenance hours in PNNL's top-performing target mix
<10% to 20% [3]
PNNL target for corrective maintenance as a share of maintenance hours
Do not monitor everything: build a criticality pyramid
The instinct after a good pilot is to put sensors on every motor, pump, and fan. That drains budget before results arrive and buries the team in data on assets that do not matter.
Tier assets by the consequence and likelihood of failure instead:
| Tier | Which assets | Monitoring approach |
|---|---|---|
| Tier 1: continuous | Failure stops a constraint, has long part lead times, or has safety consequences | Online sensors with automated alerting |
| Tier 2: periodic | Important but redundant, or failures develop slowly | Route-based readings, oil sampling, thermography on a schedule |
| Tier 3: preventive or run to failure | Cheap, redundant, or easily replaced | Time-based PM or no monitoring |
PNNL's KPI guidance gives targets for the resulting mix: predictive maintenance above 45% to 55% of maintenance hours, preventive above 25% to 35%, and corrective below 10% to 20%, each trending the right way [3]. Those targets describe a program that still relies heavily on preventive work. Nobody serious argues for continuous monitoring on every asset.
Match the modality to the failure mode
No single technology catches every fault. The DOE guide's predictive technologies chapter covers thermography, lubricant and wear particle analysis, ultrasonic analysis, vibration analysis, motor analysis, and performance trending as distinct tools with different applications [1]. A scaled program maps each Tier 1 and Tier 2 asset's dominant failure modes to the technology that detects them:
| Failure mode | Primary technology | Often paired with |
|---|---|---|
| Bearing wear, imbalance, misalignment, looseness | Vibration analysis | Temperature |
| Electrical faults, connection problems | Thermography | Motor current analysis |
| Gear and internal wear, lubricant breakdown | Oil and wear particle analysis | Vibration |
| Slow-speed bearings, leaks, steam traps | Ultrasound | Thermography |
| Rotor and winding problems | Motor current analysis | Vibration |
Fewer assets with the right combination of technologies often beats more assets with vibration alone.
Route-based or wireless: do the math with your own numbers
Route-based collection with a handheld analyzer is cheaper to start and labor-heavy to run. Wireless continuous sensors cost more up front and cut walking time, but add gateways, network work, batteries, and software subscriptions. The crossover depends on your labor rate, route length, number of points, and how often you need readings.
Here is an illustrative modeled estimate of route labor alone: about $3,240 a year for a monthly 40-asset route. Model inputs: a $45 hourly technician rate, 6 hours per route including walking, setup, and data checks, and 12 routes a year. Compare that, and the value of readings more often than monthly on Tier 1 assets, with installed quotes for wireless sensors on the same points, plus gateways and subscriptions.
Do not forget network integration. Wireless sensors in brownfield plants face concrete, steel, and interference, and every new device on the plant network triggers a security review. NIST SP 800-82r3, the federal Guide to Operational Technology Security, provides guidance on securing OT while addressing its performance, reliability, and safety requirements [4]. Engage IT and OT security before you buy hardware, not after.
Multi-vendor integration is the silent killer
At scale, most plants end up with sensors and software from more than one vendor, plus a historian and a CMMS. If each tool keeps its own asset list and alert format, analysts spend their time reconciling systems instead of diagnosing machines.
Three rules keep this manageable:
- One asset identity. Every sensor point maps to exactly one CMMS asset ID. See our guide to why predictive alerts point to the wrong asset.
- Open data paths. Prefer standard interfaces for getting data out of each tool. OPC UA, for example, is a platform-independent, service-oriented architecture with information modeling and built-in security controls [5].
- Alerts land in one place. Route every validated alert into a single triage queue that creates CMMS work orders, rather than separate vendor dashboards. Our CMMS integration guide covers the mechanics.
Alert fatigue will stall the program before sensors fail
Factory-default thresholds on hundreds of sensors produce more alerts than any team can investigate. When most alerts turn out to be nothing, technicians stop looking, and the program loses the trust it needs.
Control alert volume deliberately:
- Baseline each asset across its normal operating range before enabling alerts.
- Gate alerts by operating state. Suppress during startup, cleaning, changeover, and idle, using run status from the historian or controller.
- Tier severity. Advisory findings go to a weekly review; only high-confidence, high-consequence alerts interrupt someone.
- Measure and tune. Track alerts per asset, the share that lead to work, and false positives, and adjust thresholds monthly.
Treat alert volume as a design budget
Decide how many alerts your team can properly investigate each week before you scale. If the forecast volume exceeds that budget, tighten thresholds, add operating-state gates, or slow the rollout. Adding sensors faster than the team can absorb alerts is how scaled programs get abandoned.
The staffing model nobody plans for
A scaled program needs defined roles, not heroics:
| Role | Responsibility |
|---|---|
| Program owner | Criticality tiers, budget, targets, and reporting |
| Analyst or service provider | Diagnoses alerts, sets thresholds, maintains baselines |
| Planner | Turns validated findings into scheduled work orders |
| Technicians | Confirm findings, record what they found, and flag wrong-asset or no-fault results |
| IT/OT contact | Network paths, device security, and integration support |
The DOE guide's advice applies here too: if you cannot staff analysis in-house, contracting it can be the better option [1]. What you cannot skip is the feedback loop from technicians, because confirmed and rejected findings are what make the alerts better over time.
A 90-day scaling playbook
Days 1 to 30: foundation
Complete the criticality ranking and tier list. Map failure modes to technologies for Tier 1 and Tier 2 assets. Verify asset identity end to end for the first expansion wave. Agree the alert budget and the success measures.
Days 31 to 60: integration
Connect sensors and route alerts into a single triage queue that drafts CMMS work orders. Add operating-state gating. Run in shadow mode, with planners reviewing drafts rather than receiving live work.
Days 61 to 90: calibration
Tune thresholds against technician feedback. Go live for the assets whose alerts are proving useful. Report alerts per asset, share leading to work, false positives, and confirmed catches, then decide the next wave from those numbers.
What success looks like at month 12
At the end of the first year, a healthy program can show a stable alert volume the team can handle, a rising share of alerts that lead to useful work, a growing log of confirmed catches with their avoided costs, and a maintenance mix trending toward the PNNL targets [3]. For the financial side, see our predictive maintenance ROI guide.
Frequently asked questions
Why do condition monitoring pilots fail to scale?
Because the pilot depended on one person hand-tuning a few assets. At scale, criticality tiers, integration, alert management, and staffing have to replace that individual effort.
Should every asset get continuous monitoring?
No. Continuous monitoring belongs on assets whose failure is costly, slow to repair, or unsafe. Others are better served by periodic checks or preventive maintenance.
When does wireless monitoring beat route-based collection?
When the labor and missed-warning cost of routes exceeds the installed, network, and subscription cost of wireless on the same points. Calculate it with your own labor rates and point counts.
How do you prevent alert fatigue?
Baseline each asset, gate alerts by operating state, tier severity, and tune thresholds monthly against what technicians actually find.
References
[1] U.S. Department of Energy, Federal Energy Management Program, "Operations and Maintenance Best Practices Guide, Release 3.0," 2010. https://www.energy.gov/sites/prod/files/2020/04/f74/omguide_complete_w-eo-disclaimer.pdf
[2] NIST, "Research Suggests Significant Benefits to Investing in Advanced Machinery Maintenance," 2020. https://www.nist.gov/news-events/news/2020/06/research-suggests-significant-benefits-investing-advanced-machinery
[3] Pacific Northwest National Laboratory, "Applying Key Performance Indicators." https://www.pnnl.gov/projects/om-best-practices/applying-key-performance-indicators
[4] NIST, "SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security," September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final
[5] OPC Foundation, "Unified Architecture." https://opcfoundation.org/about/opc-technologies/opc-ua/
Related articles
Ready to put this into practice?
See how Monitory helps manufacturing teams implement these strategies.