Alarm on-delay and off-delay are timers that make an alarm wait before it reacts - refusing to annunciate until a condition has lasted long enough to be real, and refusing to clear until the value has genuinely settled. They are the standard cure for momentary and transient alarms, the brief blips that would otherwise pepper the operator with events for conditions that came and went in a second. This page explains how on-delay and off-delay timers work, when to use time-based filtering instead of deadband, and how they keep a monitoring stream free of noise.
Alarm On-Delay and Off-Delay in one line: An alarm on-delay is a timer that requires the alarm condition to remain continuously present for a set time before the alarm actually annunciates, so brief spikes that clear on their own never reach the operator. An alarm off-delay is the mirror image: it requires the value to stay in the normal range for a set time before the alarm is allowed to clear, preventing rapid re-firing during a noisy recovery. Together this time-based filtering suppresses momentary and transient alarms, complementing deadband, which acts on amplitude rather than time.
Which page do you need? This page focuses on tuning the delay timers to reduce nuisance alarms. For what on-delay and off-delay mean, see Alarm On-Delay and Off-Delay.
An on-delay works by starting a timer the moment the alarm condition first appears and only annunciating the alarm if the condition is still present when that timer expires. If the value crosses the setpoint but falls back before the delay elapses, the timer resets and no alarm is ever raised - the momentary excursion is filtered out entirely. Only conditions that persist for at least the delay period make it through to the operator. This is exactly what is wanted for measurements prone to brief, self-correcting spikes, where the transient carries no useful information and would only add noise to the log.
An off-delay applies the same waiting logic to clearing. Once an alarm is active, the off-delay requires the value to remain back in the normal range continuously for the set time before the alarm is permitted to return to normal. If the value dips back into alarm during that window, the clear timer resets and the alarm stays active. This stops an alarm from flickering off and on during a jittery recovery, where the value crosses the boundary repeatedly on its way back to normal. The two delays are independent settings - a given alarm might use an on-delay, an off-delay, both, or neither - and choosing which to apply depends on whether the noise problem is at the onset of the condition, during its recovery, or both.
Time delays and deadband both fight nuisance alarms, but they attack the problem along different axes, and the best choice depends on the nature of the noise. Deadband works on amplitude: it stops chatter caused by the value oscillating within a small band around the setpoint, by requiring the value to move a meaningful distance before the alarm clears. Time delay works on duration: it stops nuisance alarms caused by brief excursions, by requiring the condition to last a meaningful time before the alarm annunciates. A short, sharp spike that shoots well past the setpoint and back is not caught by deadband - it crosses the whole band - but an on-delay filters it out easily.
In practice the two are often combined, because real signals can be both noisy in amplitude and prone to transients. A typical approach is to set an appropriate deadband to handle jitter around the threshold and add a modest on-delay to swallow brief spikes, so the alarm only fires for a genuine, sustained excursion. The one thing to watch with delays is that they trade responsiveness for quiet: an on-delay, by design, holds back the alarm for its duration, so it must be kept short enough that it does not meaningfully delay a real, fast-developing problem. For that reason delays are sized to be just long enough to reject the transients seen in normal operation and no longer, and they are not used at all where every second of early warning counts.
In a SCADA or cloud monitoring system, on-delay and off-delay are configured per alarm alongside the setpoint and deadband, and they are what keep transient blips from becoming a flood of events in the history. Because the platform time-stamps everything, an alarm that fires and clears within a second or two, over and over, is easy to spot as a transient problem, and adding a short on-delay is the natural fix. Delays are especially valuable for point types that are inherently flaky in short bursts, such as a digital status that bounces or a measurement that spikes during switching.
For a platform such as Merobix, monitoring remote oil and gas sites, delays matter most because alarms often turn into notifications pushed to someone away from the location. A momentary pressure spike, a brief communications glitch, or a sensor that blips for an instant could otherwise fire an alert and wake someone for a condition that lasted a second and resolved itself. An on-delay ensures the alert only goes out for a condition that has genuinely persisted, so the notifications that reach the operator represent real, sustained situations worth their attention rather than transient noise.
Off-delay plays a quieter but useful role in remote monitoring by smoothing the recovery. When a value is coming back to normal after an upset - a level draining down, a pressure settling out - it can bounce across the boundary several times before it truly stabilizes, and without an off-delay each bounce would send a clear-then-alarm pair to the dashboard and possibly the notification stream. A short off-delay lets the value settle before the alarm is declared clear, so the operator sees one clean return-to-normal instead of a stutter, which keeps the picture of a recovering site accurate and calm.
An on-delay requires the alarm condition to persist continuously for a set time before the alarm annunciates, filtering out brief spikes that clear on their own. An off-delay requires the value to stay back in the normal range for a set time before the alarm is allowed to clear, preventing the alarm from flickering during a jittery recovery. One filters the onset of the condition; the other filters its clearing.
Use a delay when the nuisance comes from brief, transient excursions - a value that spikes well past the setpoint and back in a moment - because deadband, which works on amplitude, will not catch a spike that crosses the whole band. Use deadband when the nuisance comes from the value oscillating within a small band around the setpoint. The two are often combined, with deadband handling jitter and a short on-delay handling transients.
It can be if set too long, because by design it holds back the alarm for its duration, which delays the operator learning about a real, fast-developing problem. For that reason delays are kept just long enough to reject the transients seen in normal operation and no longer, and they are generally avoided on fast-acting critical alarms where every second of early warning matters. Sizing the delay against the actual transient behavior of the signal keeps it safe.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.