Alert fatigue is one of the most underappreciated problems in distribution grid operations. When an alert system produces 80 notifications per shift and operators learn through experience that 70 of them require no action, they stop reading them carefully. The system that was supposed to surface actionable conditions becomes noise, and the genuinely urgent condition gets missed in the volume.
The threshold design problem
Most SCADA alerting systems let you set threshold triggers on load readings. Load exceeds X amperes, alert fires. The engineering problem is not getting alerts faster. The problem is making sure each alert represents a condition that actually warrants operator attention, specifically a condition that will not self-resolve before the operator can act and that has a meaningful downside if it goes unaddressed.
That second requirement is where static thresholds break down. A feeder load spike that would be alarming at 2:00 AM in January might be completely normal at 3:00 PM in July. A threshold calibrated for summer peak loads will fire constantly in mild weather. A threshold calibrated for mild weather will miss legitimate stress events at peak.
Dynamic thresholds and forecast context
Ampgrove's alerting layer uses a different model: instead of comparing current load to a static threshold, we compare current load to what the load should be at this hour, day type, and temperature, and we flag deviations from forecast. An alert fires when measured load is deviating from the model's expectation by more than the historical deviation baseline for this feeder.
This produces alerts that mean something. A feeder running 12 percent above its forecast at this hour is a signal that something unexpected is happening. A feeder running at its expected peak load is not an alert condition, even if that load is high in absolute terms.
Designing for operator workflow
The second design consideration is how alerts fit into how operators actually work. A well-designed alert contains everything the operator needs to decide on a first response without opening another system. That means the alert includes the current reading, the forecast expectation, the deviation magnitude, and the feeder's recent trend. It should answer the question: is this getting better or worse?
We have found that operators respond better to alerts that show a 30-minute history alongside the current condition. A spike that is already trending down is a different operational situation than a spike that is still climbing. The same load reading has a different urgency profile depending on its direction of movement.
Calibrating after deployment
Threshold calibration is not a one-time setup task. We review alert firing rates with our utility partners quarterly, looking at total alert volume, the ratio of alerts that resulted in operator action, and the number of conditions that generated significant events without prior alerting. Those three numbers together give you a picture of whether your alert system is too sensitive, insufficiently sensitive, or about right.
A well-calibrated system should have an alert-to-action ratio above 0.6. If fewer than 60 percent of alerts require operator action, you are probably generating too much noise. If you are seeing reliability events that were not preceded by an alert, your thresholds are set too conservatively.
Alert priority tiers and escalation design
Not all alerts warrant the same urgency of response. A well-designed alert system has explicit priority tiers with different notification channels and response time expectations for each tier. A tier 1 alert for a feeder approaching 95 percent of rated capacity with a rising trend should trigger an immediate page to the on-call dispatcher. A tier 3 informational alert for a feeder that is slightly above its forecast baseline on a low-risk hour can go to a dashboard log that operators review at natural workflow break points.
Mixing these alert types into a single notification channel is one of the most common alerting system design failures we encounter. When tier 1 and tier 3 alerts arrive through the same channel, operators cannot distinguish urgency without reading each alert individually. The result is either that operators read every alert carefully (unsustainable at volume) or develop a habit of scanning alerts quickly and occasionally missing the urgent ones in the noise.
Integration with existing operator workflow tools
Alert design cannot be evaluated in isolation from how operators currently receive and act on information. Utilities that have invested in modern EMS consoles with integrated notification capabilities have different integration requirements than utilities where the primary operator interface is a legacy SCADA display with limited notification functionality.
Ampgrove's alerting layer supports delivery via email, SMS, and webhook integration for utilities that want to pipe alerts into existing notification infrastructure. We do not require operators to adopt a new primary interface to get value from the alerting system. An alert delivered as an SMS to the on-call dispatcher's cell phone, with the key numbers and the recommended action, is often more operationally useful than an alert displayed only on a dashboard that the dispatcher has to navigate to.
The after-action review process
Quarterly alert calibration reviews should include after-action analysis of events where alerts did not fire as expected or where alerts fired and no action was required. These two categories reveal the most about where threshold calibration needs adjustment.
A missed event is one where a reliability-affecting condition developed without an alert being generated ahead of it. The investigation question is: did the forecasting model not predict the developing condition, or did the threshold not trigger even though the model had the forecast? These are different problems requiring different fixes. A model accuracy issue suggests retraining or feature engineering work. A threshold design issue suggests recalibrating the alert trigger for that feeder type or weather condition.
At Ampgrove, we track missed events alongside alert-to-action ratios as the two primary metrics of alerting system performance. Our utility partners receive a quarterly summary of both metrics for their active feeders, with an analysis of any significant missed events and the threshold or model factors that contributed to them. This review cadence is part of the standard production engagement, not a separate consulting service.