A measurement that momentarily crosses a limit and immediately returns is not usually a real problem, but a naive alarm will announce it anyway - and if the value hovers on the threshold, it will announce it again and again. On-delay and off-delay are the timers that fix this. An on-delay makes a condition prove it is real by persisting before the alarm is raised; an off-delay makes it prove it is really gone before the alarm clears. This page explains these time-based delays and how they suppress transient and chattering alarms.
Alarm On-Delay / Off-Delay in one line: An alarm on-delay requires the alarm condition to remain true continuously for a set time before the alarm is actually raised, filtering out brief spikes that would otherwise trigger false alarms. An off-delay requires the condition to stay clear for a set time before the alarm is allowed to return to normal, preventing a value that is bouncing around the threshold from chattering on and off. Both are persistence timers that trade a small amount of detection delay for a large reduction in nuisance alarms.
The on-delay answers a simple question: has this condition lasted long enough to be worth an operator's attention? When a value crosses an alarm limit, the on-delay timer starts, and the alarm is only raised if the value is still in the alarm state when the timer expires. A pressure that spikes across a high limit for a fraction of a second and drops back never survives an on-delay of even a few seconds, so the operator is never bothered by it. Only a condition that actually persists gets announced.
This directly targets transient alarms - the brief, self-clearing excursions caused by pump starts, valve strokes, measurement noise, or a passing slug of fluid. Without an on-delay, every one of these becomes an alarm that appears and clears before anyone can even read it, cluttering the alarm summary and training operators to ignore alarms as noise. With a sensible on-delay, the fleeting events are filtered out at the source and only genuine, sustained conditions reach the operator.
The cost of an on-delay is detection latency: the alarm is deliberately delayed by the timer's length, so a real condition takes that much longer to be announced. This is why the delay is chosen against the process, not set to a blanket value. A slow tank level can tolerate a long on-delay because nothing bad happens in a few seconds, whereas a fast, safety-relevant condition must have a short delay or none at all, because the time cost of waiting could matter. The timer is a tuning decision, not a universal setting.
The off-delay handles the opposite half of the problem: a value that sits right on the threshold and wobbles across it repeatedly. Each time it dips back below the limit, a plain alarm would clear; each time it rises again, the alarm would return. The result is chatter - the same alarm cycling on and off many times a minute, generating a stream of near-identical entries that bury real events. The off-delay breaks this by requiring the condition to stay clear for a set time before the alarm is allowed to return to normal.
With an off-delay in place, a value that drops below the limit for only a moment does not clear the alarm; the alarm holds until the value has stayed clear for the full delay. If the value bounces back into alarm before the off-delay expires, the alarm simply remains active as one continuous event rather than a burst of separate ones. The operator sees a single, stable alarm that reflects the underlying condition instead of a flurry that reflects only the noise on the signal.
On-delay, off-delay, and deadband are complementary tools that attack chattering from different angles, and it is worth being clear how they differ. Deadband separates the trip and reset thresholds so the value must move by a real margin to clear - it works in the amplitude dimension. On-delay and off-delay work in the time dimension, requiring the condition to persist. A value that chatters because of small amplitude noise is best handled with deadband; one that chatters because of brief timing excursions is best handled with delays. Many systems use both together, and choosing the right combination is a core part of alarm tuning.
On remote oil and gas sites, transient and chattering alarms are especially costly because there is often no one on location, and every alarm may become a phone call or a page. An on-delay of a few seconds on a pressure or level point can eliminate the flood of self-clearing spikes that pump cycling and slugging produce, so the after-hours callout list contains only conditions that genuinely persisted. That directly reduces nuisance callouts without hiding real problems.
A cloud SCADA platform such as Merobix applies these delays consistently and centrally, so the same on-delay and off-delay tuning can be rolled out across many similar wells rather than configured by hand at each one. Because the delays are evaluated in the platform, a chattering point discovered on one site can be fixed there and the fix propagated to every identical site, turning a per-site annoyance into a one-time tuning decision. Consistent delays across a fleet also make the alarm summary comparable from site to site.
The judgment that must not be lost is that a delay is a filter, and a filter can hide as well as help. An on-delay set too long on a fast, consequential condition delays the very alarm that most needs to be prompt, so delays are applied deliberately - generous on slow, tolerant points, short or absent on fast, safety-relevant ones. Used with that discipline, on-delay and off-delay quietly remove most of the noise from a remote alarm system while leaving the alarms that matter fully responsive.
An on-delay is a timer that requires an alarm condition to stay true continuously for a set period before the alarm is actually raised. It filters out brief spikes that cross a limit and immediately return, so momentary excursions never become alarms. The tradeoff is that a genuine condition is announced a few seconds later than it otherwise would be.
An off-delay requires the condition to stay clear for a set time before the alarm is allowed to return to normal. If a value bounces below the limit only briefly and rises again, the alarm holds as one continuous event instead of clearing and re-triggering. This turns a burst of near-identical entries into a single stable alarm.
Use a deadband when a value chatters because of small amplitude noise near the threshold, since deadband separates the trip and reset points by a margin. Use on-delay or off-delay when the chatter comes from brief timing excursions that a persistence timer can filter out. Many systems use both together, matching the tool to whether the noise is in amplitude or in time.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.