How many alerts is too many, and how do I stop people ignoring them?
Budget alerts by the responder, not by the system. Most people can absorb a handful a week and still act on each. Past that, response collapses and the whole channel dies, including the alerts that mattered. Set each threshold so it fires about as often as you would genuinely want someone to stop what they are doing, then measure the share that get acted on.
Response rate is the health metric, not alert count
Nobody instruments their alerts, which is why alert systems decay silently. Every alert should be acknowledgeable, and the acknowledgement should be recorded. Once you can see the share of alerts that produced any action at all, you can tell a tuned system from a decorative one.
A falling response rate is the leading indicator that a channel is dying. It falls before people complain, and long before they mute the thread.
A simple instrument works: a link in every alert that records who opened it and what they did. Even a two-button acknowledgement gives you enough to compute response rate per rule, which immediately identifies the three rules generating most of the volume and none of the action.
Five ways to cut volume without losing coverage
- Tune to intervention capacity. Raise the threshold until the alert fires roughly as often as someone is actually available to respond. Sensitivity you cannot staff is not sensitivity.
- Require persistence. Fire on two consecutive periods outside the band rather than one. This removes most single-period noise at almost no cost in detection.
- Add an absolute floor. A relative rule alone will alert on tiny numbers behaving normally. Require both a percentage move and a material absolute move.
- Deduplicate per entity. One alert per location per condition per day, not one per occurrence.
- Batch the non-urgent. Anything that can wait until tomorrow morning belongs in a daily brief, not in an interrupt.
Severity tiers buy you different interruptions
Three tiers cover most service businesses. Immediate interrupts are reserved for conditions that decay within hours, like a phone queue backing up or a location with no jobs dispatched by mid-morning. Same-day items go into a single afternoon digest. Everything else rolls into the weekly review.
The tier decides the channel. Immediate goes to a phone. Same-day goes to email or a task in the system where the work happens. Weekly goes into a document someone reads with coffee.
Getting the tier wrong in either direction is costly. Put a same-day item on someone's phone and you have spent an interruption on something that could have waited. Put a decaying condition in a weekly digest and by the time anyone reads it the jobs are gone. When in doubt, ask how much of the value is lost per hour of delay; that number picks the tier.
Retire alerts on a schedule
Alert rules accumulate. Someone adds one during a bad quarter, the situation resolves, and the rule keeps firing for years. Every rule should carry an owner and a review date. If nothing has been acted on in ninety days, downgrade it to a brief line or delete it.
Treating alert rules as a maintained inventory rather than a pile is the difference between operational AI that people trust and a notification channel everybody has muted.
Topics: alerting · exception reporting · thresholds · adoption
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.