How Long Should an Alarm Delay Be? Set It From Process Time, Not a Default

A low-flow alarm on a cooling pump fired 41 times in one shift. The operator's fix request was one line: "add a delay." We added a 3-second on-delay and the chatter stopped. Then someone copied that same delay onto the pump's seal-fail alarm, and now the pump trips before the warning ever reaches the screen. That is the whole problem with alarm timers in one sentence — the knob that kills noise can also hide the first real warning, and it is the same knob.

An alarm delay changes when an operator is called to act, so it belongs in the alarm design, not in the pile of display settings you tweak live. ISA-18.2 (published as IEC 62682) treats delay-on, delay-off, and deadband as attributes of the alarm decided during rationalization — not values tuned by whoever is annoyed on a given day. Before you set one, it should survive five questions:

What field condition is being filtered?
How long can that condition exist before anyone has to act?
Does the PLC, the SCADA server, or the alarm subsystem own the timer?
Is it applied to activation, to return-to-normal, or to both?
What happens to it during communication loss, mode changes, and PLC restart?

If nobody can answer those, the timer isn't engineering. It's masking a nuisance alarm that should have been fixed at the switch, the threshold, or the deadband.

The reason this matters at all: EEMUA 191 puts the target long-term alarm rate below one alarm per ten minutes per operator in steady operation, and ISA-18.2's own metrics are similar. Miss that by an order of magnitude and operators stop reading the list — so the temptation is always to bury the rate under delays instead of fixing the sources. Delays are the second tool, not the first.

Separate debounce, on-delay, and off-delay

These terms are often mixed together during commissioning. They solve different problems.

Timer type	Practical use	Field caution
Input debounce	Filter contact bounce or noisy discrete inputs	Should usually be close to the input source
Alarm on-delay	Require the abnormal condition to persist before alarming	Can hide short but important events
Alarm off-delay	Keep alarm active briefly after the condition clears	Can make intermittent faults easier to see
Return-to-normal delay	Delay the normal state in the alarm list	Can confuse operators if not shown clearly
Command feedback timeout	Detect command issued but field state did not follow	This is not the same as alarm debounce

A vibrating level switch needs input debounce. A low-flow alarm during pump start needs an on-delay. A valve travel fault needs a command feedback timeout. Point one global alarm delay at all three and each one behaves wrong in a different way.

One thing that gets forgotten in the timer argument: for analog alarms, deadband does most of the anti-chatter work before any timer runs. A level transmitter riding right at the high setpoint with 0.3% noise will toggle the alarm dozens of times a minute, and a delay only smears that toggling out — deadband stops it. Common starting points are around 5% of range on flow, 2% on pressure, 1% on temperature, then widen from there for signals you know are noisy. Set the deadband first, measure what's left, and only then decide whether a timer is needed at all.

Put fast safety logic in the PLC

Do not rely on an HMI or SCADA alarm delay for protective action. If a condition must stop equipment, interlock equipment, or protect people, the logic belongs in the PLC, safety PLC, drive, or protection relay as appropriate.

SCADA alarm timing is useful for operator notification and event handling. It should not be the only place that decides whether a motor trips, a heater shuts down, or a valve closes.

For critical signals, document both layers:

Protective trip logic and scan time in the controller.
Operator alarm timing in the alarm server.
Historian sampling or event capture used for investigation.
HMI indication during the timing period.

This prevents a common handover problem: the HMI alarm has a 10 second delay, but the PLC trip has no delay, so the equipment stops before the operator ever sees the warning alarm.

Choose the delay from process behavior

Start with the equipment behavior, not with a default value copied from another project.

Examples:

A pump low discharge pressure alarm may be delayed during startup while the line fills.
A compressed air low pressure alarm may need only a short delay because downstream tools will fault quickly.
A tank high level warning should not be delayed past the time needed for operator response.
A conveyor jam photoeye may need debounce for product flutter, but a long delay can damage product.
A temperature high alarm on a slow vessel may not need much debounce because noise is small compared with process lag.

For each alarm, compare the delay against the operator response time plus the time to consequence. My rule of thumb: keep the on-delay under about a third of the time from alarm to consequence, and never let delay plus response time exceed it. If a tank overflows 90 seconds after high level and the operator needs 30 seconds to react, a 60-second "de-bounce" delay isn't filtering noise — it's guaranteeing the spill. When a signal is that noisy and that fast, the fix is deadband or a better sensor location, not more delay.

Show timing state where it helps operations

Some timers should be visible. Operators do not need to see every internal counter, but they should understand why an alarm has not appeared yet or why it remains active after recovery.

Useful HMI indications include:

"Start delay active" on pump, fan, or compressor faceplates.
Remaining travel timeout for valves and dampers.
A diagnostic bit showing that input debounce is active because a contact is chattering.
Alarm detail text that states the delay value and condition.
Maintenance view with raw input, filtered input, and alarm state.

This is especially helpful when operators report that an alarm is random. Often the alarm is not random; the timing rule is invisible.

Avoid delay stacking

Delay stacking happens when several layers each add a small delay and nobody owns the total.

A real path may look like this:

Field switch debounce in a remote I/O module.
PLC input filter.
PLC alarm on-delay.
OPC UA or Modbus polling interval.
SCADA alarm delay.
Alarm notification or paging delay.

Each layer may look reasonable alone. Together they can turn a 2 second issue into a 20 second operator notification. During commissioning, time-stamp the raw input, PLC alarm bit, SCADA alarm, and operator notification. The measured chain is more useful than the configured numbers.

Treat communication loss separately

Communication loss should not pass through the same timer assumptions as process alarms. If the PLC link is bad, a level switch is not proved normal just because the last value was normal. If the alarm server holds last value during a timeout, delayed alarms can behave in misleading ways.

Define these cases explicitly:

Bad quality before the alarm condition becomes true.
Bad quality while an alarm delay is running.
Bad quality after an alarm is active.
PLC restart while timers are nonzero.
Redundant server failover while delayed alarms exist.

For important alarms, test the behavior by forcing communication loss. Do not rely on the vendor default description.

Commissioning checks

Use a small test sheet for timed alarms. Include both normal and abnormal timing.

Verify the raw input changes at the expected field condition.
Measure debounce or filter time at the PLC tag.
Force a short pulse shorter than the delay and confirm no operator alarm is created.
Hold the condition longer than the delay and confirm timestamp, priority, and message.
Clear the condition and confirm off-delay or return-to-normal behavior.
Restart the PLC or alarm service and confirm timers do not create false alarms.
Check historian events so alarm review can explain what happened later.

Where possible, use real time measurements from logs instead of watching a screen with a stopwatch.

Common failure modes

A global 5 second delay is applied to every alarm, including fast equipment faults.
A nuisance alarm is delayed instead of fixing a loose switch, bad threshold, or wrong deadband.
The alarm delay is in SCADA, but the PLC event and historian show a different time sequence.
Off-delay keeps alarms active after recovery with no explanation on the HMI.
Communication bad quality freezes the input and prevents the delayed alarm from completing.
A restart clears active timing and hides a condition that was already abnormal.
Operators receive a page long after the alarm cleared because notification delay was not considered.

Handover notes

For alarms with timers, leave behind more than a number. Record the reason, owner, test result, and acceptable future change range. A timer value that makes sense for a small pump skid may be dangerous on a larger unit with different fill time, valve stroke time, or trip consequence.

Good alarm timing should make the alarm system quieter without making the plant less transparent.