Too many is any number your team cannot act on within the response time you promised. There is no universal count. Set an alert budget by dividing the hours people can spend on alerts by the time each one really takes, then cut or reroute the rest.
What an alert budget is
An alert budget is a cap on interrupting alerts per person per week. Borrowing the idea from reliability engineering, it forces a trade: if you want a new alert type, you must retire one or reroute it to a digest. The budget protects the thing alerts spend, which is attention.
How to calculate yours
Use your own data rather than a borrowed benchmark.
- Count the hours per week the team can honestly give to security alerts.
- Measure the average handling time for one actionable alert, from opening to a decision. Sample ten recent ones.
- Divide hours by handling time. That is your ceiling for actionable alerts.
- Subtract a margin for incidents, usually a third or so, so one bad week does not break the system.
If the result is lower than the number of alerts you receive, the gap is your noise problem, and it will not go away by working harder.
What to cut or reroute first
| Candidate | Why it goes first | Where it goes instead |
|---|---|---|
| Duplicate findings across repos | Same fix, many alerts | One grouped item |
| Findings in development only dependencies | Rarely reach production | Weekly digest |
| Findings with no reachable path | Cannot be triggered by your code | Backlog with review date |
| Alerts nobody acted on in 90 days | Evidence they do not matter | Retire or tune |
GitHub's auto-triage documentation describes presets such as dismissing low impact issues for development scoped dependencies, which shows that vendors treat this as a standard noise reducer. Auto-dismissed alerts remain available for reporting and can be reopened, which keeps the audit trail.
Track whether the budget works
Watch three numbers monthly: alerts per person, share of alerts that led to action, and median time to first response. If the action share is low, tune. If response time creeps up, cut. If an incident revealed a finding that sat in a digest, move that alert type up a tier.
For a deeper look at the cost side, see the cost of a false positive.
Where Safeguard fits
Safeguard's reachability analysis helps remove findings in code paths you never call, which shrinks the number that interrupt people. Try a free scan to see how a project's findings group.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the finding count before and after reachability is applied.
Quick check
Is it safe to auto-dismiss alerts?
It can be, if rules are narrow, logged and reviewed. GitHub's documentation notes auto-dismissed alerts can be reopened when metadata changes.
What if the budget is smaller than the real problem?
Then say so to leadership. Either add capacity, reduce the attack surface, or accept the documented risk.
Sources
Last reviewed: 19 October 2026.
