Skip to main content

How many alerts is too many, and how do I stop people ignoring them?

Dashboards & Reporting Published August 7, 2026
Short Answer

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.

Related Answers

People who read this also asked

Browse the Answer Hub →

AI is easy to access. Making it useful is hard.

Bluefrog makes AI useful by integrating it with the way your business actually works — your software, your calls, your customers, your marketing and your revenue.

Technology development since 1997 · AI integration platforms since 2001