A fixed alarm makes a simple promise: it will tell you when something is wrong. The catch is *when*. A hard limit only speaks after a variable has already crossed a line you set - and by then the failure is usually well underway. The early warning you actually wanted lived in the hours or days before that crossing, in signals a fixed threshold was never built to see.
This post answers a scoped question: why do traditional, threshold-based alerts miss early warning signals - and what kind of monitoring catches them instead?
This is the *missed-problem* side of alarms. Its twin - alarms that fire too often and bury the real ones - is covered in our post on reducing false alarms with machine learning. For the head-to-head, see threshold alarms vs AI anomaly detection.
What a traditional alert actually does
A fixed alert watches one tag and fires when it crosses a static limit: bearing temperature over 80 C, pressure under 2 bar. It is simple, transparent, and essential for safety trips. But it answers only one question - *is this value bad right now?* - and it answers it the instant the value is already bad.
Degradation rarely arrives as a sudden jump. A bearing heats a little more each day; a pump draws slightly more current; vibration creeps up run after run. On any single reading, everything looks fine - right up to the moment it crosses the line. The threshold did not fail; it was simply never designed to notice a slow, multi-signal drift.
Why fixed alerts miss the early signal
Five limitations, and each one costs lead time:
- They watch one variable at a time, so a pattern that only shows up across temperature, current and vibration together is invisible.
- They use a static limit with no context, so the same number applies at startup, full load and cleaning - which forces you to set it loose.
- They have no sense of trend, so a value creeping up for a week looks identical to a stable one until the crossing.
- They cannot combine signals, and the earliest evidence usually lives in the relationship between tags, not in any single one.
- They get tuned to avoid nuisance, so limits are widened to stop false alarms - and the early-warning margin widens away with them.
What catches the early signal instead
Anomaly detection learns what *normal* looks like for your equipment - per product, speed and state - across many signals at once. Instead of a single hard line, it models the normal relationship between tags and flags when that relationship starts to drift, even while every individual reading is still inside its limit. That is where the days of lead time come from. (See our primer on what anomaly detection is.) You keep the hard thresholds for safety; you add pattern detection for early warning.
Use case in practice: an ammonia refrigeration compressor (beverage plant)
Central refrigeration keeps a beverage plant's tanks and process cooling within spec. The screw compressor has the usual protection trips: high discharge temperature, low oil pressure, high motor current. For two weeks a bearing has been degrading. Discharge temperature drifts up half a degree a day, motor current rises a percent, and a vibration band grows - all still comfortably inside every trip setting. Nothing alarms. Then, on a hot afternoon at peak load, discharge temperature finally crosses the trip and the compressor shuts down - taking process cooling with it during the worst possible shift.
How you would build it
- Signals: discharge and oil temperatures, oil pressure, motor current, suction/discharge pressure, and a vibration band from the compressor - straight off the PLC and a low-cost vibration sensor.
- Context: ambient temperature, cooling load, running state (on / startup / unloaded), so normal is defined for each condition instead of one global limit.
- What you label: the past bearing and oil-related shutdowns and service events, so the model learns the multi-signal shape that precedes them. (This labeling step is the whole game - see our post on what data labeling is.)
- Who reacts: the plant maintenance lead gets an early-warning alert - days before the trip - with the drift chart, and schedules the bearing change into planned downtime instead of a peak-load emergency.
A quick worked example
Say the bearing signature is detectable for ten days before the trip fires. A fixed threshold gives you zero of those days - it speaks at hour zero of the failure. Pattern detection flags the drift on day two or three, turning an unplanned shutdown of central cooling during peak demand into a fifteen-minute planned bearing swap on a night shift. Same sensors, same data - the difference is monitoring that reads the trend instead of waiting for the line.
Practical rule
Keep every safety threshold - they are not the problem. Just stop asking a fixed limit to give you early warning it was never built to provide. Add monitoring that learns normal across your signals and reacts to drift, and the warning arrives while you still have options.
Early warning is learned from your history. Label your past failures and the signals around them - import your data, add context, and mark the events in Predsense labeling: https://www.predsense.ai/products/labeling