Home / Insights / Vibration monitoring pitfalls
Condition Monitoring 8 min read Published 16 June 2026

Why most vibration-based motor monitoring projects are doomed to fail

By Frank Guo · Technology & Product Leadership, addanode

TL;DR — Vibration monitoring works. Most projects still fail — not on the technology, but on scoping. The five killers are: monitoring the wrong assets, drowning people in false alarms, never linking a reading to a maintenance action, ignoring South African realities (load shedding, dust, skills), and buying sensors before defining the decision they support. Start from a criticality list, instrument only where downtime cost justifies it, baseline each machine, route alerts to a named person, and tie every alarm to a work order. Do that and a condition-monitoring programme pays back. Skip it and you've bought expensive vibration wallpaper.

Who this is for

Reliability engineers, maintenance managers and plant owners in South African manufacturing, mining and water who have been pitched a "predictive maintenance" or "Industry 4.0" vibration package — or tried one — and want to know why these projects so often end up as ignored dashboards.

The uncomfortable truth

Vibration analysis is one of the most mature and reliable predictive-maintenance techniques in existence. Bearings, imbalance, misalignment and looseness all announce themselves in the vibration signature weeks before failure. The physics is not in question.

And yet a large share of vibration-monitoring deployments quietly fail — the sensors get installed, the dashboard goes live, and eighteen months later nobody opens it and breakdowns are no lower than before. The failure is almost never the sensor. It's the way the project was scoped and run.

Decision rule: if a vendor leads with "how many sensors" before asking "which assets, and what decision will the data drive," they are selling hardware, not reliability. Walk the other way.

The five failure modes

1. Monitoring the wrong assets

The most common mistake is instrumenting whatever is easy to reach, or everything at once, instead of what matters. A vibration sensor on a non-critical fan that can be swapped in an hour returns almost nothing; the same spend on the main mill drive or a critical pump can save a shift of lost production. Condition monitoring only pays where the failure it prevents is expensive or dangerous.

2. Alarm flooding

Set thresholds wrong — or set them generically instead of per-machine — and the system cries wolf. After the tenth false alarm, people stop looking. Every alert that isn't actionable trains your team to ignore the next one, including the real one. Baselining each asset to its own normal behaviour is not optional; it's the difference between a tool and a nuisance.

3. No link to a maintenance action

A reading that doesn't trigger a decision is just data. Many projects stop at "we can see vibration trends" and never close the loop: who gets the alert, what do they do, and where is the work order? If an alarm doesn't become a planned intervention with an owner and a deadline, the programme has no effect on downtime — which is the only thing it was bought to change.

4. Ignoring South African site realities

A platform designed for a German factory makes assumptions that don't hold here. Load shedding kills cloud-only systems that don't buffer at the edge. Dust and heat shorten sensor life if the hardware isn't rated for it. And a system that needs a scarce, expensive vibration analyst to interpret every reading won't survive the first time that person leaves. The programme has to fit the site, the power, and the skills you actually have.

5. Buying sensors before defining the decision

The root cause behind the other four: starting from the technology instead of the decision. The right sequence is decision → data → sensor, not sensor → data → hope. Decide what you're trying to prevent and who will act on the warning, then work backwards to the minimum sensing that supports it.

Four ways it fails, and the one that causes them Vibration programmes rarely fail on the physics. They fail on scope: instrumenting what is easy to reach rather than what is expensive to lose, thresholds that cry wolf until nobody looks, alarms that never become work orders, and a platform built for a site with reliable power and a resident analyst. All four follow from starting at the sensor instead of the decision. The failure mode What it actually looks like Monitoring the wrong assets Condition monitoring pays only where the failure it prevents is expensive or dangerous. A sensor on a fan that can be swapped in an hour returns almost nothing. Alarm flooding Thresholds set generically instead of per machine. After the tenth false alarm people stop looking — including at the real one. No link to a maintenance action A reading that triggers no decision is just data. Unless an alarm becomes a planned intervention with an owner and a date, downtime does not move. Ignoring the site you actually have Cloud-only systems die with the power, dust and heat shorten sensor life, and a programme that needs a scarce analyst does not survive that person leaving. Buying sensors before defining the decision The root cause of the other four. The sequence is decision, then data, then sensor — not sensor, then data, then hope.
Four ways it fails, and the one that causes them Scope, thresholds, the missing work order, and the site — all from starting at the sensor. The failure → What it looks like Monitoring the wrong assets Condition monitoring pays only where the failure it prevents is expensive or dangerous. A sensor on a fan that can be swapped in an hour returns almost nothing. Alarm flooding Thresholds set generically instead of per machine. After the tenth false alarm people stop looking — including at the real one. No link to a maintenance action A reading that triggers no decision is just data. Unless an alarm becomes a planned intervention with an owner and a date, downtime does not move. Ignoring the site you actually have Cloud-only systems die with the power, dust and heat shorten sensor life, and a programme that needs a scarce analyst does not survive that person leaving. Buying sensors before defining the decision The root cause of the other four. The sequence is decision, then data, then sensor — not sensor, then data, then hope.
The five failure modes above, and what each looks like on a real site. The fifth causes the other four — decision, then data, then sensor, is the sequence; starting at the sensor is what produces all of them.

How to scope one that actually works

  • Start from a criticality ranking. List rotating assets by what their failure costs you — lost production, safety, repair, lead time on spares. Instrument from the top down, only while the maths works.
  • Baseline every machine. Capture normal behaviour first, then set thresholds to that machine, not to a generic table.
  • Route alerts to a named person. Not a mailing list. One owner per asset, with an escalation path.
  • Close the loop into a work order. Every actionable alert becomes a planned job with an owner and a date — ideally integrated with your CMMS.
  • Design for the site. Edge buffering for load shedding, hardware rated for dust and heat, and trending simple enough that your existing team can act without a full-time analyst.
  • Start small, prove it, scale. A handful of critical machines that demonstrably avoid one breakdown will fund the rollout — and build the internal trust the programme needs.

What "good" looks like after 90 days

A working programme isn't measured in sensors installed; it's measured in breakdowns avoided and alarms acted on. Within about 90 days you should see: a short, trusted alert stream (not noise), at least one developing fault caught and planned out of a breakdown, and maintenance crews who open the dashboard because it has earned their attention. If instead you have a wall of red alarms nobody reads, the scoping was wrong — and adding more sensors will make it worse, not better.

This is exactly how we approach asset & condition monitoring at addanode: criticality first, decision-led, and built to survive South African conditions. It runs on the same addaNet platform as your OEE and energy data, so reliability sits in one picture instead of a silo.

Frequently asked questions

Is wireless vibration monitoring accurate enough, or do we need wired analysers?

For trend-based early warning on most plant assets, wireless sensors are more than accurate enough and far cheaper to deploy. For detailed root-cause diagnostics on the most critical machines, combine them with higher-rate measurement where it's justified. Match the tool to the decision, not the brochure.

Which assets should we monitor first?

Rank rotating equipment by the cost and risk of its failure — main drives, critical pumps, fans, compressors, gearboxes whose stoppage halts production or threatens safety. Instrument from the top of that list down, only while the payback holds.

How do we stop the system from flooding us with false alarms?

Baseline each machine to its own normal behaviour, set thresholds per asset rather than from a generic table, and route alerts to a named owner with an escalation path. An alert should mean "go look," never "ignore me."

Will it keep working through load shedding?

It should. Choose edge devices that buffer locally and sync when power and connectivity return, so you don't lose the record of what happened during an outage. Cloud-only systems with no edge buffering are a poor fit for South African sites.

Do we need a full-time vibration analyst to run it?

Not for a well-scoped programme. Automated baselining and trend alerting let your existing maintenance team act on clear warnings. Specialist analysis is reserved for the few critical machines and the occasional deep diagnosis — not every reading.

Thinking about condition monitoring?

Send us your critical-asset list. We'll tell you honestly which machines are worth monitoring — and which aren't — before you spend on a single sensor.

Book a Discovery Call See the solution →

Related reading

Solution

Asset & Condition Monitoring

How we scope for payback, not sensor count.
9 min read

Choosing IoT connectivity in SA

4G vs LoRaWAN vs NB-IoT vs Sigfox, by use case.
Solution

addaNet IoT Platform

One platform for condition, OEE and energy data.

Primary sources