False alarms in structural monitoring are reduced by removing their causes, not by one higher threshold. First check the reference, temperature, boundary oscillation, duplicates, cadence and notification routing. Hysteresis stabilises the state, repeat lockout (cooldown) reduces message frequency, acknowledgement identifies the owner, and temporary silencing handles a known exception. Each mechanism solves a different problem.
In brief
- A false alarm has a wrong basis; a nuisance alarm may be technically true but add no new information.
- Hysteresis changes the return condition to a lower state. It does not delay the first exceedance.
- Cooldown limits follow-up notifications, but it should not hide escalation from WARNING to ALARM.
- Acknowledgement does not clear the state. It records who took over the event and when.
- Percentiles from history can suggest an operating threshold. They do not replace the design limit or the engineer's judgement.
Alarm fatigue starts earlier than an ignored SMS
Alarm fatigue is a drop in a team's ability to notice and handle important events correctly under the pressure of too many, repeated or low-quality alarms. The problem is not only the number of messages. It starts when the operator can no longer tell a new risk from another copy of the same state.
In structural and geotechnical monitoring, alarms are rarer than in a process control room, but ignoring one can have greater consequences. One tilt channel oscillating around a threshold can generate dozens of state changes during a daily temperature cycle. If every return and re-exceedance sends an SMS, after a few days the team learns to silence the phone, not the asset.
Three categories need to be separated.
A true and useful alarm detects a condition covered by the procedure and adds new information that requires action.
A nuisance alarm may correctly reflect the threshold, but it appears too often without changing the decision. An example is the fifth notification about the same sustained exceedance.
A false alarm comes from wrong data, poor configuration or misinterpretation. The sensor is disconnected, the reference is wrong, the unit is mixed up or temperature was not taken into account, and the system presents the result as a structural phenomenon.
Raising the threshold may silence all three categories, but it may also hide a real event. That is why tuning starts with classification, not with editing the number.
Five mechanisms that must not be mixed up
| Mechanism | What it changes | What it does not do | When to use it |
|---|---|---|---|
| Threshold | the boundary for entering WARNING or ALARM | it does not stabilise oscillation by itself | when the limit comes from design, a standard or an approved analysis |
| Hysteresis | the boundary for leaving a raised state | it does not delay the first entry | when the value oscillates near the threshold |
| Cooldown | the time until the next notification about the same state | it does not change the state and does not fix the rule | when the team already knows the event and repeats do not change the response |
| Acknowledgement | the owner and takeover time | it does not lower the value or close the phenomenon | when parallel confusion must be avoided and evidence retained |
| Silence until date | temporary disabling of messages in a known window | it should not remove data and history | during planned works, testing or a known exception |
How hysteresis works
Assume an illustrative WARNING threshold of 10 units and a hysteresis of 1 unit. The state enters WARNING when the value reaches 10. It does not return to OK at 9.99. It returns only below 9. This means natural noise between 9.8 and 10.2 does not switch the state every moment.
Hysteresis is not a "safety" buffer and should not be set without a unit and direction. For a lower alarm, the condition works in reverse. For multi-level thresholds, both the OK to WARNING boundary and the WARNING to ALARM boundary must be defined.
How cooldown works
Cooldown starts after a notification is sent and limits follow-up messages for a defined time. The state may still be ALARM, and the data history still updates. A good solution does not block a significant escalation. If the first message concerned WARNING and five minutes later the value moved into ALARM, the recipient should get new information despite the cooldown.
A cooldown that is too long can hide a change in context. One that is too short will not relieve the on-call operator. It should be selected according to response time and event dynamics, not the team's patience.
What acknowledgement means
Acknowledgement says: "I see the event and I am taking over its handling." It does not mean: "the asset is safe" or "the alarm was false". The user and the time should remain in the history. If the state rises from WARNING to ALARM after acknowledgement, the procedure may require a new notification and a separate response.
When to silence
Silence is appropriate during a planned test, work that safely changes the measurement, or a known fault awaiting service, provided there is an alternative control. It must have an end. Indefinite silencing turns an alarm into decoration. After the expiry date, the system should return to assessment without manual "remembering".
Seven sources of alarm noise
1. A threshold copied from another asset
The same value and unit do not mean the same risk mechanism. A threshold should come from the design, an approved observational method, the standard relevant to the purpose, or a baseline period assessed by an engineer. Copying a value from a previous project creates a false sense of standardisation.
2. A wrong baseline period
If the reference was set during an unstable phase, under unusual temperature or after partial loading, every later value inherits the offset. Resetting to zero after every alarm is even worse: it removes continuity of evidence. Changing the reference requires context, a note and an audit trail.
3. Temperature influence
A daily or seasonal cycle can drive a channel across the threshold without a lasting structural change. The answer is not an automatic "temperature subtraction" without validation. You need to compare the relationship before and after compensation, the model residuals and other channels. Correlation does not prove causation.
4. Oscillation around the boundary
This is the classic case for hysteresis. If the noise amplitude is comparable to the deadband, the state will toggle. Hysteresis should be selected according to measurement variability and resolution, but it must not close the return path for weeks.
5. Duplicates and delayed data
A repeat transmission of the same sample should not evaluate the event as new again. The idempotency key must link source, channel and time. Delayed data should also not roll back the current state or create an alarm "from the past" without an explicit rule.
6. One timeout for all channels
A NO_DATA alarm set to 60 minutes will be late for a minute-based source and false for a two-hour source. The window depends on the actual cadence, batch sending and criticality. Missing data has a different cause and a different procedure than an exceedance.
7. Poor notification routing
A technically correct alarm sent to too many people becomes organisationally wrong. The recipient should have a role, the ability to act and a minimum level of information. The administrator is not always the on-call person, and the board does not need every warning state.
How to tune thresholds from history without replacing design with statistics
History answers the question "how did the channel behave", not "which value is safe". A high percentile can be a useful operating suggestion, but if the structure operated too close to the boundary throughout the period, statistics only describe a bad state.
The correct sequence is:
- confirm the unit, reference, formula and data quality;
- identify the design or code limit, if one exists;
- choose a representative baseline period covering normal loads and temperatures;
- review the distribution, seasonality, jumps and gaps;
- calculate how many events candidate thresholds would trigger;
- assess each historical exceedance in context;
- approve the change by an authorised person;
- retain the old and new values and the effective date;
- observe the result for a defined period;
- roll back the change manually if the hypothesis was wrong - do not assume automatic restoration of the previous state.
Statistics can also show that the threshold is not the problem. If most notifications come from one channel during a daily temperature cycle, check compensation first. If they all appear after a transmission gap, check ordering and idempotency. If every alarm is real, but the team does not take a different action, change the notification routing or procedure, not the safety limit.
Illustrative example: 42 messages from one channel
A tilt channel has a WARNING threshold of 2.0 mrad. Over one week the value oscillates between 1.92 and 2.08 mrad, mainly with temperature. A system without hysteresis sends 42 notifications about entries and exits. This is an illustrative example.
The analysis shows:
- all state changes occur at similar times;
- the adjacent temperature channel has a strong correlation;
- after cooling, the value returns;
- there is no lasting offset after the cycle;
- the data are complete and fresh.
A possible plan does not start by raising the threshold to 2.2 mrad. First the engineer verifies the temperature model and the reference. Then they consider hysteresis, for example 0.15 mrad, and a cooldown for repeat messages in the same state. The first entry into WARNING is still immediate. Return requires moving clearly below the boundary. If the value rises to ALARM, the new message bypasses the cooldown.
After the change, the team measures the result for two weeks: number of transitions, messages, acknowledgements, response time and events without an owner. Success is not zero alarms. Success is fewer repeats without losing a significant event.
Metrics that show whether the alarm system works
| Metric | How to read it | Pitfall |
|---|---|---|
| Alarms per channel and week | identifies sources of noise | do not compare channels with different roles without context |
| Notifications per event | shows the effectiveness of repeat lockout and message routing | too low a result may hide escalation |
| Time to acknowledgement | measures operational response | a quick click does not prove the right decision |
| Share of unacknowledged events | reveals lack of an owner | some events may not require ack under the procedure |
| Time in WARNING/ALARM | shows long exposure periods | it does not say whether the value was steadily increasing |
| Alarms later found false in analysis | supports root-cause review | requires consistent classification |
| Silences past expiry | detects exceptions that became normal | silence itself is not an error |
Add one quality question: "Did the message change the decision?" If not, check whether it was a needed confirmation of sustained risk or just a copy.
Limits of tuning from history
Tuning on historical data does not define load-bearing capacity, allowable displacement or the safety limit. It shows the distribution of past values and the expected message frequency for a candidate rule. If the baseline period includes an unnoticed problem, statistics may treat it as normal. That is why the result must always be compared with the design, the relevant standard, work conditions and the assessment of the responsible engineer.
There is also no honest guarantee of zero false alarms. The aim is to detect their sources, reduce repeats and keep sensitivity to important events. Hysteresis, repeat lockout and silence do not replace the alarm response plan. If the organisation has no owner, no response time and no alternative evidence, platform configuration alone will not close the risk.
How it looks in Inclify
In Inclify, every standard threshold alarm can have a WARNING and ALARM level per channel, as well as hysteresis. The state is evaluated transactionally, and the history retains transitions, value and user. Cooldown limits repeat notifications; escalation from WARNING to ALARM can send a new message despite an active cooldown. De-escalation also remains visible.
The operator can acknowledge an active alarm, which records the person and time. They can also silence it until a specified date, within the maximum supported by the interface, and lift the silence earlier. Notifications work by e-mail, SMS and app according to user preferences. There is no mobile push, no automatic escalation to additional people, no minimum duration for exceedance, and no rate-of-change alarm.
The tuning report analyses historical percentiles, proposes WARNING and ALARM values, and estimates the number of events per week. An approved administrator can apply the proposal for standard threshold alarms. This is an operational aid, not automatic safety optimisation. The proposal should be compared with the design, context and change history.
Changing an alarm configuration leaves the values before and after, plus the operation time, in the log. This trail helps reconstruct the decision, but it does not provide automatic restoration of the old configuration.
Review checklist for recurring alarms
- Were the data complete and fresh?
- Are the unit, reference and formula current?
- Was the exceedance real in measurement terms?
- Was the value related to temperature or the work phase?
- Did multiple messages refer to one sustained state?
- Does the hysteresis match the noise and resolution?
- Does the cooldown allow significant escalation?
- Did the right person receive the right level?
- Was the alarm acknowledged and was the decision recorded?
- Did the silence have a reason, alternative control and end date?
- Does the threshold come from the design, a standard or an approved analysis?
- Does the rule change have an owner and a record of values before and after the change?
Make changes in batches. If you change the threshold, hysteresis, repeat lockout and notification routing at the same time, you will not know what worked.
FAQ
What is the difference between a false alarm and a nuisance alarm?
A false alarm is based on wrong data, configuration or interpretation and does not reflect the actual state of the measured quantity. A nuisance alarm may be technically true, but it appears too often or adds no new information. The first needs data diagnostics; the second often needs hysteresis, cooldown, routing or procedure adjustments.
Does hysteresis delay the first alarm?
No. Typical hysteresis keeps the entry threshold unchanged and shifts the return threshold. If WARNING starts at 10, the state enters at 10 just as fast. It may return to OK only below a lower value, for example 9. This prevents noise around 10 from generating a series of toggles.
What cooldown is appropriate?
One that matches response time and event dynamics while not blocking important escalation. There is no universal value. Start from the procedure: after how many minutes does a repeat message add new value? Test a WARNING moving into ALARM. Repeat lockout should not replace hysteresis or repair a wrong threshold.
Does acknowledgement close the alarm?
No. Acknowledgement records that a specific person has seen and taken over the event. The state depends on subsequent data and the rule. The alarm may remain active, escalate or return to OK. In the procedure, acknowledgement, operational decision, cause removal and formal incident closure should be separated. A click alone is not proof of safety.
Can a percentile define the safety threshold?
Not on its own. It describes the distribution of observed values, not the load-bearing capacity or allowable structural behaviour. It can suggest an operating threshold or show the expected message frequency. The safety limit is set by the design, the relevant standard and the engineer's judgement. Statistics cannot legalise a historically bad state or replace independent verification.
When may an alarm be silenced?
During a known, approved exception: testing, planned service or works that predictably change the measurement, provided there is an alternative control. Silence must have an owner, a reason and an end date. It should not remove data or history. Indefinite disabling without alternative observation creates a blind spot. After the expiry date, the rule must be checked and restored.
Can false alarms be eliminated entirely?
There is no honest guarantee of zero. Sensors, transmission, environment and models have uncertainty. The goal is to detect causes, reduce repeats and keep sensitivity to significant events. Measure message count, acknowledgement time, post-analysis classification and events without an owner. Every change must be auditable.
Sources and further reading
- USACE EM 1110-2-1908 - instrumentation, thresholds, data assessment and response.
- FERC: Dam Safety Surveillance and Monitoring - organisation of surveillance and monitoring.
- Research article: false alarm reduction in SHM - research on methods for reducing false alarms; application requires validation for the specific system.
- NIST TN 2118: False Alarm Testing for Radiation Detection Systems - an official example of how a high false-alarm rate affects operator response and false-alarm-rate test design.
- Warning and alarm thresholds: how to set them - sources of limits and the response plan.
- No data alarm: how to set NO_DATA - a separate procedure for loss of observability.
What next
Do you have a channel that generates most of the notifications? Let's review its history and alarm rule. You will see whether the problem lies in the threshold, hysteresis, temperature, data quality or notification routing before anyone raises the limit.