Alarm deadband is the deliberate gap between the value at which an alarm activates and the value at which it is allowed to clear, and it is the single most effective tool for stopping an alarm from chattering. Without it, an alarm uses one number for both trip and reset, so a measurement resting right on its setpoint fires and clears endlessly. This page explains what alarm deadband is, how the separate trip and reset points work, and how to size the band so it kills chatter without hiding real changes.
Alarm Deadband in one line: Alarm deadband, a form of hysteresis, is the gap between an alarm's trip point and its reset point. An alarm activates when the measurement crosses the trip point, but it will not return to normal until the value has moved back past a separate reset point offset from the trip by the deadband amount. This gap prevents small oscillations around the setpoint from repeatedly re-triggering the alarm, which is the primary defense against chattering alarms, and it is applied specifically to alarming rather than to control or data storage.
An alarm without deadband is defined by a single threshold: cross it going up and the alarm activates, cross it going down and the alarm clears. The problem is that a real measurement resting exactly at that threshold is constantly jittering a little above and a little below it, from noise and small process movement, so the alarm activates and clears on every tiny crossing. Deadband fixes this by splitting the one threshold into two. For a high alarm, the alarm still activates at the trip point, but it will only clear once the value has fallen back below a reset point set a defined distance below the trip. The width of that gap is the deadband.
The effect is that once the alarm is active, small oscillations no longer clear it, because the value would have to travel the full width of the deadband in the downward direction before the system accepts that the condition is over. A measurement wobbling by a small amount around the trip point stays firmly in the active state instead of flickering, so a single genuine excursion produces one alarm and one return-to-normal rather than a burst of them. For a low alarm the arrangement mirrors this: the alarm trips when the value falls below the trip point and only clears once it rises back above a reset point set above the trip. In both cases the reset point is placed on the normal side of the trip point, so the value has to genuinely return toward normal before the alarm relaxes.
Choosing the deadband is a balance. Too narrow, and it does not span the normal noise on the signal, so the alarm still chatters. Too wide, and the alarm clears only after the value has recovered well into the normal range, which can mask that the process is still hovering near trouble and can delay a return-to-normal indication the operator is waiting for. The practical rule is to make the deadband comfortably larger than the ordinary noise band of that particular measurement, so routine jitter is absorbed, while keeping it small enough that a meaningful move back toward normal is still reflected promptly. Deadband is often expressed as a percentage of the measurement span, with different values appropriate for quiet signals versus noisy ones like flow.
Deadband is a per-point setting because signals differ enormously in how noisy they are. A steady temperature might need only a small deadband, while a turbulent flow or a splashing level can need a much larger one to stay quiet. This is why deadband is tuned rather than set to a single global figure, and why cleaning up a chattering alarm usually starts by widening its deadband to suit its actual noise. When deadband alone is not enough - typically because the signal oscillates slowly enough that even a wide band gets crossed both ways - it is paired with a time delay, so the condition must also persist before the alarm annunciates or clears. Alarm deadband is also distinct from other things sharing the name: it is not the control deadband that keeps a controller from reacting to small errors, and it is not the historian compression deadband that decides which samples to store; it applies specifically to when an alarm activates and clears.
In a SCADA or cloud monitoring platform, alarm deadband is configured alongside each alarm's setpoint, and getting it right is what keeps the alarm log and the notification stream clean. Because the platform records every alarm event, a point with too little deadband reveals itself as a tag that trips and clears many times over a short window, and the fix is usually to widen its deadband to match the noise the platform can see in the underlying trend. Tuning deadband is therefore one of the first and highest-value actions when reducing alarm load on a monitored system.
For a platform such as Merobix, watching remote oil and gas sites, deadband is what stops a borderline measurement from turning into a stream of repeat notifications to someone off site. A level sensor sitting near its high setpoint on a windy day, or a pressure jittering right at its limit, would otherwise send an alert every time it crossed the line - potentially many times an hour, at all hours. A properly sized deadband means the operator gets one alert when the value genuinely goes high and one when it genuinely recovers, rather than a cascade for a condition that is barely moving.
Because deadband must be matched to each signal's real noise, having the historian trend right next to the alarm configuration is a practical advantage. An engineer can look at how much a measurement actually wobbles in normal operation and set the deadband to sit just outside that band, using observed behavior rather than a guess. On a cloud platform that keeps both the trend history and the alarm settings together, that tuning loop is quick, which is exactly what makes it feasible to keep alarm deadbands well set across a large fleet of monitored points.
Alarm deadband creates a gap between the value at which an alarm trips and the value at which it clears, so small oscillations around the setpoint cannot repeatedly re-trigger it. This is the primary way to stop a chattering alarm, where a measurement resting at its threshold fires and clears endlessly. It ensures a single genuine excursion produces one alarm and one return-to-normal instead of a burst.
Make the deadband comfortably wider than the normal noise on that specific measurement so routine jitter is absorbed, but keep it small enough that a real move back toward normal is still reflected promptly. It is often expressed as a percentage of span and tuned per point, since a quiet temperature needs a small band while a noisy flow or splashing level needs a larger one. Looking at the actual trend to see how much the signal wobbles is the practical way to set it.
No. Alarm deadband governs when an alarm activates and clears, using separate trip and reset points to prevent chatter. Control deadband instead keeps a controller from reacting to small errors around its setpoint, and historian compression deadband decides which samples are worth storing. They share a name and the idea of a tolerance band, but they act on different parts of the system.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.