A single fixed limit cannot tell the difference between a value that is normal for one situation and dangerous for another. A pump's discharge pressure that is perfectly fine while it is running would be an obvious fault if it appeared while the pump is supposedly off - but a static setpoint treats both the same and cannot tell them apart. Condition-based alerting fixes this by making the alarm limits depend on the asset's current operating state, so the same measurement is judged against the standard that fits the moment. This guide explains how condition-based alerting differs from fixed-threshold alarms, and how making alerts state-aware cuts the nuisance alarms that plague static schemes.
Condition-based alerting in one line: Condition-based alerting evaluates a measurement against limits that change with the asset's current operating condition or context, rather than against a single static setpoint. The same tag might have different acceptable ranges depending on whether equipment is running or idle, or the alert might be based on deviation from a learned normal baseline. By making alarm limits state-aware, it raises alerts that fit the situation and suppresses the false alarms a fixed threshold would generate.
The traditional way to alarm a measurement is a fixed threshold: a single setpoint that stays constant, so the alarm fires whenever the value crosses it regardless of anything else going on. It is simple, predictable, and easy to configure, and for many measurements it is entirely adequate - a tank that should never exceed a certain level can be alarmed at a fixed high limit and left there. When there is one correct limit that holds in all circumstances, a fixed threshold is the right tool and there is no reason to complicate it.
The limitation appears when the correct limit is not actually constant, because it depends on what the asset is doing. Consider a pump's discharge pressure. While the pump is running, a healthy pressure sits in a certain range, and a fixed high and low limit around that range makes sense. But while the pump is stopped, the pressure should be near zero, and the running limits are meaningless - a fixed low-pressure alarm set for the running state would scream continuously every time the pump is deliberately off. One static setpoint cannot be right for both states, so whatever value is chosen is wrong for one of them.
This mismatch is a major source of nuisance alarms. When a fixed threshold does not fit the current situation, it produces alerts that are technically correct against the number but useless or misleading in context - the low-pressure alarm on a pump that is simply off, the low-flow alarm on a well that is intentionally shut in, the deviation alarm during a planned transition. Operators learn that these alarms do not mean anything actionable and begin to tune them out, which is exactly how a flood of context-blind alarms erodes trust in the alarm system as a whole. The fixed threshold is not wrong about the number; it is blind to the state that would tell it whether the number matters.
Condition-based alerting removes the blindness by letting the alarm limits depend on the asset's current state. Instead of one fixed setpoint, the alert logic knows what mode the asset is in and applies the limits that fit that mode. For the pump, it applies the running-pressure limits only while the pump is running, and different logic - perhaps expecting near-zero pressure - while it is stopped. The same measurement is now judged against the standard appropriate to the moment, so a normal running pressure does not alarm, and a pressure that is wrong for the current state does. The alarm becomes meaningful in a way a single threshold could never be.
There is more than one way to make an alert condition-aware. The most direct is state-based limits, where explicit operating modes - running, stopped, starting, in maintenance - each carry their own thresholds, and the system selects the right set based on the asset's current mode. Another approach compares the value to a learned baseline of what is normal for the asset under the current conditions, alerting on deviation from that baseline rather than on crossing a fixed line, which lets the notion of normal itself adapt. Both share the same principle: the yardstick the value is measured against is chosen to match the situation rather than being fixed for all time.
The payoff is a large reduction in nuisance alarms without sacrificing real detection. Because the alert only fires when a value is genuinely wrong for the current state, the alarms that reach the operator are the ones that actually mean something, and the context-driven false alarms - the off-pump low-pressure nag, the shut-in well's low-flow complaint - simply disappear because the logic knows those states and does not alarm on them. It is important to distinguish this from condition-based maintenance, which uses an asset's condition to decide when to service it; condition-based alerting uses the asset's condition to decide what counts as an alarm-worthy deviation right now. One schedules maintenance from condition; the other shapes alarming from condition.
For an oil and gas operation monitoring many remote, unmanned sites, nuisance alarms are more than an annoyance - they are a direct threat to the monitoring model. When one operator is responsible for a large fleet through exception-based surveillance, their capacity depends on the exceptions being real; every context-blind false alarm consumes attention that should be reserved for genuine problems and pushes them toward tuning out alerts that might one day matter. Condition-based alerting protects the operator's attention by making sure the alarms that reach them are ones that fit the current state of the asset and therefore actually warrant a look.
The variability of field assets makes state-awareness especially valuable. Wells are shut in and brought back; pumps and compressors cycle between running and idle; facilities move through planned transitions and maintenance. Each of these states changes what normal looks like, and a fixed-threshold scheme generates a burst of meaningless alarms every time an asset legitimately changes mode. Condition-based logic that understands these states keeps quiet through them, so an operator watching a fleet is not buried under alarms every time a pump is deliberately cycled or a well is intentionally taken offline.
A cloud SCADA platform such as Merobix is well positioned to apply condition-based alerting because it holds the live state of every asset alongside its measurements, so it can select the right limits for the current mode or compare a value to a learned baseline in one place. That lets the alerting adapt to what each asset is actually doing across the whole fleet, suppressing the context-driven false alarms that would otherwise flood the exception view and keeping the operator's worklist populated with deviations that genuinely fit the situation. For an operation whose entire remote-monitoring premise rests on alarms being trustworthy, making the alerting state-aware is a direct investment in keeping every alert worth answering.
A fixed-threshold alarm compares a value to a single static setpoint that never changes, so it fires whenever the value crosses that line regardless of what the asset is doing. Condition-based alerting makes the limits depend on the asset's current operating state, so the same measurement is judged against the standard that fits the moment - running-pressure limits while a pump runs, different logic while it is stopped. The result is that a value which is normal for the current state does not alarm, and one that is wrong for it does.
No, though the names are similar. Condition-based maintenance uses an asset's measured condition to decide when it needs servicing, replacing fixed maintenance intervals with condition-driven ones. Condition-based alerting uses an asset's current condition or state to decide what counts as an alarm-worthy deviation right now, shaping the alarm limits rather than the maintenance schedule. One decides when to service equipment from its condition; the other decides what to alarm on from its condition.
Most nuisance alarms come from a fixed threshold not fitting the asset's current situation - a low-pressure alarm on a pump that is simply off, a low-flow alarm on a well that is intentionally shut in. Condition-based alerting knows those states and applies limits appropriate to each, so it does not alarm on values that are perfectly normal for the current mode. The false alarms driven by context blindness disappear, leaving the operator with alerts that actually warrant attention and preserving their trust in the alarm system.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.