Fixed thresholds
A single limit cannot be right at start-up, at full load and during a changeover. Thresholds tight enough to catch wear will fire every shift.
False alarms
False alarms in predictive maintenance: why they happen and how to end them
Most predictive maintenance projects are not abandoned because the model missed a failure. They are abandoned because it cried wolf until the shift stopped reading the alerts.
Short answer
False alarms come from models that score signals without knowing the machine. A deviation is only meaningful next to the asset's chronic defects, the running order and recipe, the shift and the plant environment. Build that context first and most false positives disappear before they are ever shown, because the system recognises the deviation as expected rather than new.
The five causes of a false alarm
No machine state
The same vibration means wear at steady state and nothing at all during setup. Without state, every transient becomes an event.
Chronic defects read as new
Nearly every machine has a quirk it has always had. A model that never learned it reports the same non-problem forever.
Missing production context
A harder recipe or a heavier order legitimately stresses the asset. Read as degradation, it produces an alert for doing the job.
No feedback loop
When technicians cannot mark an alert as irrelevant and have the model absorb it, the same false positive repeats until it is ignored.
How context removes them
1. Learn the asset before scoring it
During onboarding the system records the machine's known defects and weak points, so its permanent quirks become the baseline instead of a daily alarm.
2. Read every signal in its state
Start-up, changeover, steady state and cleaning each get their own normal. A deviation is measured against the state the machine is actually in.
3. Include team and environment
Shift habits, setup practice, ambient temperature and neighbouring machines explain deviations that otherwise look like failure.
4. Require evidence before showing an alert
Each alert carries the signal, the comparison and the suspected cause. Anything that cannot be explained is not worth interrupting a shift for.
5. Let people correct the model
A technician marking an alert as expected teaches the system permanently. Corrections are how context keeps up with a plant that changes.
6. Keep a person on the decision
Every proposed maintenance window is approved before it moves anything, so the system earns trust rather than assuming it.
What alert fatigue really costs
The damage is not the wasted inspection. It is the day a real warning arrives and nobody opens it, because the last eleven were nothing. Once trust is gone it does not come back with a better model, only with months of alerts that were each worth reading. That is why a predictive system should be judged on how few alerts it raises, not how many.
Common questions
- What is a false alarm in predictive maintenance?
- An alert that reports degradation where there is none — usually a normal deviation caused by a state change, a harder recipe, an environmental condition or a defect the machine has always had.
- Why do AI models generate so many false positives?
- Because they are usually trained on the signal alone. Statistically, any unusual reading is an anomaly; operationally, most unusual readings have an ordinary explanation the model was never given.
- Can you fix false alarms just by raising the thresholds?
- No. Raising thresholds trades false alarms for missed failures, which is the more expensive error. The fix is context, not a less sensitive model.
- How long before alerts become trustworthy?
- Onboarding builds most of the context up front, and the first weeks of corrections from the maintenance team close the rest. Trust follows a run of alerts that each turned out to be worth opening.
- Does the system act on an alert by itself?
- No. It proposes, with the evidence behind the proposal, and a person signs off before anything is scheduled or changed.
What makes Atherya different
Most predictive maintenance tools score signals. Atherya builds an operational memory of the plant first, then reasons on top of it — with the evidence in plain sight and the decision left to a person.
Operational memory
Every event, anomaly, intervention and shift becomes shared memory. What was a log yesterday is experience tomorrow, and the model reads new signals against it.
Déjà Vu: it has seen this before
Not just "anomaly detected", but when it already happened, how similar it was, how it evolved and which action worked. The senior maintainer's memory, available to everyone.
Context that kills false alarms
Machine defects, weak points, how the crew actually works and the environment around the line. A deviation that is normal for that machine, that shift or that season stays quiet.
Living FMEA
FMEA, manuals and procedures become an active part of the reasoning: causes, effects, sensors and suggested actions are connected, instead of sitting in a document nobody opens.
Explainable, not magic
Every alert arrives with the signals involved, the comparable history, the failure mode and a confidence level. Data, interpretation and decision stay separate and verifiable.
It acts, with your sign-off
Atherya does not stop at the warning: it proposes the maintenance window against real orders and shifts, and replans when something changes. Nothing is applied until a person approves it.
On the data you already have
It works on PLC, SCADA, MES, ERP, maintenance records and feedback as they are — fragmented and legacy included. Sensors are added only where no existing signal carries the degradation.
One brain, not a maintenance silo
Maintenance, production and planning read the same operational state, so a predicted failure immediately becomes a scheduling question instead of a separate dashboard.
Related guides
Predictive maintenance: what it is and how it worksPredictive maintenance softwareIoT predictive maintenance: which sensors are worth itAI predictive maintenance: how the models workPredictive maintenance without new sensorsBest AI for manufacturing: platform comparisonAI for production planningAgentic scheduling in manufacturingAI on top of SAP and your ERP
Test it against your own alert history
Send one line and a month of history. We show which deviations would have been raised, and which ones we would have kept quiet.
Request a demo