A stale alarm is one that has been sitting active far longer than any alarm reasonably should - hours or days rather than minutes - quietly occupying a line on the operator's summary without prompting any action. Unlike a chattering alarm that floods the log with noise, a stale alarm is silent and persistent, and its danger is that it becomes part of the scenery. This page explains what makes an alarm stale, why a screen full of standing alarms is a hidden hazard, and how ISA-18.2 treats stale-alarm count as a key performance indicator worth tracking.
Stale Alarm in one line: A stale alarm, also called a standing or long-standing alarm, is one that has remained continuously active for longer than a defined threshold - commonly on the order of 24 hours. It signals a condition that either was never resolved, no longer needs an operator response, or was never really a valid alarm in the first place, and because it just sits on the display it clutters the alarm summary and trains operators to ignore standing entries. ISA-18.2 tracks the number of stale alarms as a health metric of the alarm system.
An alarm is meant to indicate a condition that needs a timely response and then clear once that condition is dealt with. A stale alarm has broken that contract: it activated, and then it simply never went away. Some stale alarms reflect a genuine but long-lived situation - a piece of equipment out of service for weeks, a level that is legitimately parked outside its normal band during a turnaround, or a measurement that is off for maintenance. Others are symptoms of a badly configured alarm, such as a setpoint placed inside the normal operating range so the value is essentially always in alarm, or a failed sensor reading a fixed out-of-range value.
The reason staleness is tracked separately from other alarm problems is that it points at a different failure than flooding or chatter. A stale alarm is not overwhelming the operator with events; it is eroding the credibility of the alarm summary by leaving permanent residents on it. When a handful of alarms are always present, operators stop reading the summary as a list of things to act on and start treating it as background - which is precisely the state in which a new, genuine alarm can appear amid the clutter and go unnoticed. The threshold used to declare an alarm stale is a policy choice, often set around a full day, chosen so that anything still active past it clearly is not the short-lived, act-and-clear event an alarm is supposed to be.
ISA-18.2 and the benchmark practices around it treat the count of stale alarms as one of the standard indicators of alarm system health, alongside average alarm rate, peak flood behavior, and priority distribution. The logic is simple: a healthy system should have few or no alarms that have been standing for a day or more, because a well-rationalized alarm either drives an action that clears it or should not have been an alarm at all. A rising stale-alarm count is a warning that the alarm set is drifting away from its philosophy, accumulating conditions that no one is expected to resolve.
Handling stale alarms is as much about process as about the individual points. When an alarm genuinely reflects a long-lived condition the operator cannot immediately clear - equipment removed from service, for instance - the correct move is usually to take that alarm out of service or suppress it deliberately through a controlled mechanism, with a record and a plan to restore it, rather than leaving it standing on the summary. When a stale alarm instead reveals a configuration error, such as a setpoint inside the normal range, the fix belongs back in rationalization, where the setpoint and priority are corrected. Either way, a periodic stale-alarm review is a routine part of an alarm system audit, precisely because these points otherwise accumulate unnoticed.
A SCADA or cloud monitoring platform can surface stale alarms almost for free, because it knows exactly when each active alarm first went into alarm. Comparing that activation time against a threshold produces a live list of every point that has been standing too long, sorted by how long it has been active. That list is the practical starting point for cleanup: the longest-standing alarms usually correspond either to the most neglected real conditions or to the most clearly misconfigured points, and both deserve attention.
On a platform such as Merobix, which monitors many remote and often unmanned oil and gas sites, stale alarms are especially easy to accumulate because there may be no one on location to resolve the underlying condition promptly. A stuck level switch or a sensor that has failed to a fixed reading can sit in alarm for days if nothing flags it, and it will quietly desensitize whoever is watching the dashboard to that site's alarm line. A standing report that highlights alarms active beyond the threshold turns that silent problem into a visible task.
The value of catching stale alarms goes beyond tidiness, because a long-standing alarm is frequently a data-quality flag in disguise. An alarm that has been active for days without any process reason often means a dead or drifting sensor, a communications fault freezing a value, or a switch stuck in one state - all things a remote operator wants to know about. Reviewing stale alarms therefore doubles as a low-effort way to catch failed instrumentation on sites that no one visits often.
There is no single universal number, because the threshold is a policy choice, but a common convention is to treat any alarm active continuously for about 24 hours as stale. The idea is to pick a duration well beyond how long a normal act-and-clear alarm should last, so anything still standing past it is clearly abnormal. Some sites use shorter or longer thresholds depending on their process.
A stale alarm quietly occupies the alarm summary without ever being resolved, and a summary full of permanent residents trains operators to ignore standing entries. That is dangerous because a new, genuine alarm can appear among the clutter and be overlooked. Stale alarms also often hide a failed sensor or a misconfigured setpoint, so they signal real problems even when they are not noisy.
It depends on why it is standing. If it reflects a real long-lived condition, such as out-of-service equipment, the alarm should usually be taken out of service or suppressed through a controlled mechanism with a record and a plan to restore it, rather than left active. If it reflects a configuration error, such as a setpoint inside the normal operating range or a failed sensor, the fix belongs in rationalization or maintenance.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.