# Why does my team ignore error alerts, and how do I fix alert fatigue?

Teams ignore error alerts when most of them are noise: one notification per event, duplicates of the same bug, bots and old browsers, and no owner. Fix it by alerting on a new issue or a regression rather than every event, adding frequency thresholds, filtering known noise sources, assigning owners, sending only urgent alerts to a loud channel, and deleting rules nobody acts on.

Canonical page: https://bugsly.dev/solutions/team-ignores-error-alerts. Last updated 2026-11-13. All solutions: https://bugsly.dev/solutions (list as JSON: https://bugsly.dev/solutions.json).

## Why it happens

An alert is a request for a person to stop what they are doing. People answer it only while they believe that most requests are worth it. The default setup of many error trackers breaks that belief in a week: every captured event emails the team, a bug that fires ten thousand times sends ten thousand messages, and a single browser extension or crawler that throws on every page load adds a constant stream that has nothing to do with your code. The channel becomes background noise and gets muted, and then the one alert that mattered is muted with it.

Three mechanisms make it worse. First, counting events instead of problems: the same root cause shows up as many alerts. Second, no severity: a typo in a rarely used admin page and a failing checkout look identical in the channel. Third, no owner: when an alert is addressed to everyone, nobody acts on it, and an alert that is routinely ignored teaches everyone to ignore the next one.

The fix is not to look at errors less, and it is not to buy a louder notification. It is to make each alert rare enough and specific enough that a person who gets one assumes it is real. That means changing what triggers an alert, removing the noise that never needed one, and attaching every remaining alert to someone who is responsible for it.

## How to fix alert fatigue (works with any error tracker that groups errors into issues)

1. **Alert on problems, not on events.** Make sure your tracker groups events into issues, one issue per root cause, and trigger alerts on an issue's first appearance and on its return after being fixed, not on each occurrence. A bug that happens a million times then produces one alert, and the existing issue keeps counting in the dashboard. If your current rule is any error event, replace it first; this single change removes most of the volume.
2. **Add a frequency or threshold rule for the bugs that get worse.** Some problems are important because of volume, not novelty: a known error that suddenly climbs from a handful a day to hundreds an hour. Add a rule that fires when an issue exceeds a number of events, or affects a number of users, in a time window you choose. Keep the numbers high enough that a typical day does not trigger it, then adjust after a week of real data.
3. **Remove the noise at its source.** Look at the top issues by event count and ask whether each one is your code. Common non-bugs are errors thrown by browser extensions, web crawlers, very old browsers, localhost development traffic and known third-party script failures. Filter these out before they are stored, by user agent, by origin or by message pattern, so they never count and never alert. Be careful with broad message patterns: a pattern that is too general hides real bugs.
4. **Give every alert an owner.** Map code paths to people or teams, for example by file path, URL or module, and route each alert to that owner rather than to a shared room. An owner turns an alert from a broadcast into an assignment. If nobody owns the code that threw, that is itself a finding to resolve in your next planning meeting.
5. **Route by severity: a channel for most, a page for the few.** Decide in advance what deserves to interrupt a person at night. Usually that is a regression in checkout or sign-in, or a sudden spike in the main flow. Send those to a loud destination. Send new issues in minor areas to a quiet chat channel that is read during working hours, and let the rest wait for triage.
6. **Triage weekly and delete rules nobody acts on.** Hold a short weekly review: resolve what was fixed, ignore what is not worth fixing, and look at each alert rule's record. If a rule fired many times and no one did anything, delete it or tighten it. Every rule should have an answer to the question what do we do when this fires. A smaller set of rules that people trust is better than a large set that people mute.

Typical noisy alert rules and what to replace them with

| Before (noisy rule) | Why it fails | After (rule that people act on) |
| --- | --- | --- |
| Email on every error event | One bug sends thousands of messages | Alert on a new issue, once per root cause |
| Same alert again after the bug was marked fixed and returned | No distinction between old and recurring bugs | Alert on regression: an issue reported again after being resolved |
| Alert when any error occurs on any page | Minor pages and crawlers count the same as checkout | Frequency threshold on the main flow, owner on each area |
| Everything goes to one shared channel | No owner, so nobody acts | Route by owner, and send only urgent alerts to the loud destination |
| Alerts from browser extensions, bots and old browsers | Not your code, constant volume | Filter at ingest so they are never stored or alerted |

The rule changes are practical criteria from the author, not vendor claims; no external vendor documentation is cited for this table.

## When to use Bugsly

Bugsly groups events into issues by fingerprint, so one root cause is one issue, and errors that return after being resolved are flagged as regressions. Its alert conditions are new issue, regression, event frequency, threshold, cron monitor missed, cron monitor error, uptime down and metric, and each can be sent to email, Slack, Telegram or a webhook. That covers the first two steps above directly: alert on new issue and regression, and add a frequency or threshold rule for volume.

Inbound filters drop events before they are stored: localhost, web crawlers, browser extensions, legacy browsers, message patterns and release patterns. Dropped events are counted per reason for 24 hours, so you can check what a filter is removing before you trust it. Ownership rules match path, url, module or tag patterns to an owner email. Through MCP, list_issues shows the unresolved issues in your project, and an assistant can read them with get_issue; the AI analysis on an issue is a hypothesis and can be wrong.

## When Bugsly is not the right answer

If you need paging with escalation schedules, acknowledgements and a second person called when the first does not respond, Bugsly is not that tool. It has no PagerDuty or Opsgenie action and delivers only to email, Slack, Telegram and webhooks. Use an on-call product for paging and send the few urgent alerts to it through a webhook.

Filtering and thresholds also do not replace fixing the underlying bugs. If the volume is real, the cure is to fix the top issues, not to hide them.

## Ask your AI assistant to do it

Connect the Bugsly MCP server (https://bugsly.dev/mcp), then paste:

> Assign to Bugsly: use list_issues sorted by event count for my project, then get_issue on the top 10 and tell me which look like noise from bots, extensions or old browsers, which are real bugs in my code, and which I should resolve or ignore. Do not resolve or ignore anything; show me what you found so I can approve before anything changes.

## Frequently asked questions

### What is alert fatigue?

It is the state where people stop responding to alerts because too many are irrelevant, repeated or unowned. The result is that real incidents are noticed late, or by customers.

### Should I alert on every new issue?

For a small team and a quiet app, yes, once per root cause. If new issues arrive faster than people can read them, send them to a quiet channel and reserve loud alerts for regressions and spikes.

### How do I know an alert rule should be deleted?

If it fired repeatedly and nobody did anything, or if the action when it fires is not clear, delete or tighten it. You can recreate a rule in minutes; you cannot recover trust once a channel is muted.

### Will filtering out browser extensions hide real bugs?

It can if the pattern is too broad. Start with the filters that match whole categories, check how many events each one dropped, and review the list again after a week.

## Related

- Why your team ignores error alerts (blog): https://bugsly.dev/blog/why-team-ignores-error-alerts
- How to prioritize production bugs: https://bugsly.dev/blog/how-to-prioritize-production-bugs
- How do I find out which deploy introduced a new production error?: https://bugsly.dev/solutions/which-release-broke-production