A well-known cement plant in an Indian industrial estate installed vibration sensors on twelve critical fans in its preheater tower and raw mill circuit. Within two weeks, the SCADA engineer logged three hundred and forty alerts. Most were false triggers from a bearing housing that ran ten degrees warmer during noon ambient conditions. By the end of the first month, the operations team had disabled alerting on all but two fans. The monitoring system continued logging data, but no one looked at it. This is the pattern that produces the objection that continuous monitoring generates too many alerts to be useful. The objection is accurate about that specific system. It is not accurate about the concept of monitoring.
Alert Fatigue Arises from Threshold Design, Not Sensor Density
The conventional approach to setting alert thresholds is to take a single static value-say a vibration level of seven millimetres per second-and apply it around the clock. This ignores the fact that every rotating machine has a natural operating envelope that shifts with load, ambient temperature, and process conditions. A fan that runs at 4.5 millimetres per second during the day and 3.2 at night will trigger an alert at 11 PM if the threshold is set to four. That alert is not a fault. It is a failure of the threshold to reflect operational reality.
The root cause is not too many sensors. It is too few threshold parameters. A properly designed monitoring system assigns multiple thresholds per measurement point: a daytime threshold for full-load operation, a night-time threshold for reduced load, and a gradual escalation window that requires a sustained excursion-not a single reading-before an alert fires. Without this structure, every normal operating variation generates an event, and the operator learns to ignore all of them. That is not alert fatigue from monitoring. That is alert fatigue from bad engineering.
Monitoring Everything versus Alerting on Everything Is an Operational Distinction
The objection that continuous monitoring overwhelms operators confuses two entirely separate functions. Continuous data acquisition-logging a pressure reading every sixty seconds from a distribution main-does not generate alerts. It generates time-series data. An alert is a separate logical step: a rule that examines the data and decides whether to notify someone. The decision to alert is not a property of the sensor. It is a property of the threshold logic applied after the data arrives.
In practice, a monitoring platform records hundreds of parameters per asset. Only a fraction of those parameters should ever trigger an operator notification. A temperature rise of three degrees on a compressor discharge line over six hours is a data point. The same rise over three minutes is an alert. An experienced operator wants the first as a trend review item on a dashboard and the second as a notification. The failure occurs when a system treats all changes as events. The fix is to separate the data stream from the notification stream and treat them as independent design concerns.
A Three-Level Alert Hierarchy Separates Actionable Events from Logged Data
Most industrial facilities that manage alert quality well use a tiered escalation structure. The top tier-typically labelled P1 or critical-triggers an immediate notification to a shift supervisor and a control room operator. This is reserved for conditions that indicate an imminent failure, such as a bearing temperature rising past its maximum continuous rating while vibration doubles in under ten minutes. A P1 alert is rare. A well-tuned system may generate one or two per quarter per major asset.
The second tier, P2, triggers a dashboard flag and a scheduled review during the next shift handover. This covers conditions like a gradual efficiency drop in a pump-a three percent reduction in flow at the same head pressure over four days. It is not urgent. It is diagnostic. The third tier, P3, is logged data only: a temperature deviation that stays within the operating band but trends upward over a week. No one receives a notification. The maintenance planner reviews it during the weekly work order meeting. At a large chemical processing facility in western India, this hierarchy reduced operator-disturbing alerts by more than eighty percent in the first six months, while the total number of monitored parameters increased by a factor of three.
Calibration of Alert Logic, Not Instrumentation, Is the Real Failure Point
The complaint that monitoring systems produce too many alerts is almost always a calibration problem. The sensors are working. The data is accurate. The fault is in the rules applied to that data. A common mistake is to set alerts based on absolute values without accounting for the asset's operating history. A transformer oil temperature of sixty-five degrees is unremarkable in a coastal plant running at full load during summer. The same temperature in a plant at twenty percent load during a monsoon month indicates a cooling fan failure or a blocked radiator.
The solution is adaptive thresholding. Instead of a fixed number, the alert threshold is set as a deviation from the asset's own historical baseline-plus fifteen degrees above the average at that load and ambient condition over the prior thirty days. This automatically accounts for seasonal variation, load changes, and aging asset behavior. A plant in an Indian industrial estate that switched from fixed thresholds to adaptive baselines reduced its monthly false alert count from two hundred and ten to eleven, without delaying the detection of a genuine bearing failure that occurred in the third month.
The Volume of Undetected Events in a System Without Monitoring Far Exceeds Alert Volume in a Good One
The hidden cost of using alert fatigue as a reason not to monitor is the events that never surface. A rolling mill in an industrial zone lost a main drive motor because a vibration reading rose slowly over ninety days-within the acceptable range each day but trending upward continuously. Without continuous logging, no one saw the trend. The motor seized at shift change. The unplanned downtime cost the plant a week of production. The system that would have detected the trend would also have generated exactly zero alerts until the rate of change crossed the diagnostic threshold in the final week.
The objection that monitoring generates too many alerts is a statement about the design of a particular system. It is not a statement about the value of continuous observation. A well-designed monitoring platform that logs every parameter and alerts on none of them still provides more operational information than a system that alerts on everything. The data is available for trend analysis, historical comparison, and root-cause investigation. The alerts are a separate function. The two should never be conflated. The facilities that succeed at monitoring treat the alert system as a design artefact that requires tuning, not as a fixed property of the sensors.
Facilities That Manage Alert Quality Well Invest in Threshold Tuning and Escalation Logic
Operationally mature facilities do not set thresholds once and leave them. They review alert logs monthly, identify the categories that generated the most events, and adjust the logic. If a pressure transmitter on a clean-water line triggers an alert every time the morning demand surge hits, the solution is not to disable the sensor. The solution is to widen the deadband, extend the persistence window to require three consecutive readings above threshold, or shift the threshold itself to reflect the known daily peak.
Escalation logic is equally critical. A P1 event should never be emailed to a distribution list of twelve people. It should page one person: the shift engineer. If that person does not acknowledge within a defined window, it escalates to the plant manager. If it remains unacknowledged, it reaches the operations director. This ensures that critical events receive attention without flooding every recipient. A municipal water utility that adopted this model reduced its alarm-to-acknowledgement time from forty-five minutes to under four, while cutting the total number of alerts reaching the plant manager by ninety percent.
The argument that real-time monitoring generates too many alerts to be useful is not an argument against monitoring. It is an argument against poor alert design. The data stream and the notification stream are independent. Fix the threshold logic, tune the baselines, and separate the tiers. The sensors are not the problem. The rules applied to them are. See how Olectr structures alert logic for operations teams.
