Agent sprawl means notification sprawl
As organizations adopt more AI agents and automated tools — each monitoring, flagging, or reporting on its own domain — the aggregate notification volume an individual has to triage grows in a way that rarely gets measured directly, even as the felt sense of "too many alerts" becomes a common complaint across teams that have adopted several agents in parallel.
"Too noisy" is a feeling; a noise percentage is a number you can act on
Alert fatigue advice frequently stops at "reduce unnecessary notifications" without a concrete way to identify which specific source is the actual problem. Logging total notifications against how many genuinely required action, per agent, converts a vague feeling into a specific, comparable number — a noise percentage — that identifies exactly which agent's configuration needs attention.
Why ranking by noise percentage beats looking at raw volume
An agent generating a high raw volume of notifications isn't necessarily the problem if most of them are genuinely actionable — the real signal is the ratio, not the count. An agent sending fewer total notifications but with a very low actionable rate can be a worse offender in practice, degrading trust in that notification channel specifically, and ranking by noise percentage surfaces this correctly where a raw-count view would miss it.
What crossing a high-noise threshold should trigger
An agent consistently generating notifications where the large majority don't require action is a strong candidate for reconfiguring its alert thresholds, batching its output into a periodic digest, or muting it from real-time channels entirely — not because the underlying monitoring isn't valuable, but because delivering it as a constant stream of low-value interruptions actively degrades the recipient's ability to notice the alerts that do matter.
Trend matters more than a single day's snapshot
A single day's noise percentage can be skewed by an unusual event that happened to require a burst of real action — tracking across multiple logged days reveals the actual baseline noise level for an agent, which is the number worth acting on, rather than reacting to one day's data point.
Frequently Asked Questions
A vague feeling of alert fatigue doesn't identify which specific source is the problem — logging total notifications against how many genuinely required action, per agent, converts that feeling into a specific, comparable number that points at exactly which agent's configuration needs attention.
A high raw volume isn't necessarily the problem if most notifications are genuinely actionable — the real issue is the ratio. An agent sending fewer total notifications but with a very low actionable rate can be a worse offender in practice, which ranking by percentage correctly surfaces where a raw-count view would miss it.
It's a strong candidate for reconfiguring alert thresholds, batching output into a periodic digest, or muting from real-time channels — not because the underlying monitoring lacks value, but because a constant stream of low-value interruptions degrades the recipient's ability to notice alerts that actually matter.
A single day can be skewed by an unusual event that happened to require a burst of real action — tracking across multiple logged days reveals the agent's actual baseline noise level, which is the number worth acting on rather than reacting to one day's data point.
No. All data is stored locally in your browser via localStorage — nothing is uploaded, making this safe to use for tracking internal tool and agent notification patterns.