You can measure alert fatigue with data you already have. Track four numbers: how often findings are dismissed without a change, how long they sit before anyone opens them, how often fixes are reopened, and how often people bypass checks. Rising values in these signal fatigue.
Define it first
Alert fatigue is the state where people stop responding to alerts because too many are low value. It is a behavior, so measure behavior, not opinions. For background on the cost, see the arithmetic of a false positive.
The four numbers
1. Dismissal rate. The share of findings closed without a code change, such as false positive or not applicable. Compute it per rule and per team. A rule near the top of this list is a fatigue source.
2. Time to first view. The time from a finding appearing to someone opening it. Findings that nobody opens for days are being ignored. Compare the median across teams and over months.
3. Reopen rate. The share of closed findings that return. A high rate may mean closures are rushed or fixes are shallow.
4. Bypass count. How often people use an exception, skip a check, or force a merge. Bypasses are a vote against a control. For related practices, see break glass workflow design.
Where to pull each one
| Number | Typical source |
|---|---|
| Dismissal rate | Scanner or platform findings export, by status and reason |
| Time to first view | Alert timestamps and view or comment events, where available |
| Reopen rate | Finding history |
| Bypass count | Branch protection logs, exception register, audit events |
If a number is not available, note the gap. Do not estimate and present it as measured.
How to read the results
- Trend, not snapshot. Look at four to eight weeks.
- Compare to fixes. If dismissals rise while fixes fall, signal quality is dropping.
- Drill into rules. Sort by dismissals to find the top few rules.
- Split by lane. Look at pull request findings separately from scheduled ones, as in who should get a security finding.
Beware of vanity changes
Metrics can improve for the wrong reasons. If you hide findings, dismissals fall and so does coverage. Pair fatigue measures with a coverage measure, such as the share of repositories scanned, so you notice if the list shrank because the tool stopped looking. See check every repository is scanned.
Also watch for Goodhart effects. If a team is graded on dismissal rate, they may dismiss less and ignore more. See Goodhart's law and security metrics.
What to do with the numbers
- Retire or tune the top three noisiest rules each month.
- Move low priority checks to a digest.
- Review bypass reasons for patterns, such as one flaky check.
- Share the results with developers, including what you will change.
A simple monthly report
One page: the four numbers with arrows for direction, the three rules you changed, and one thing you will do next month. Keep it short so it gets read.
Safeguard's reachability analysis and policy controls are designed to reduce low value findings, and the free scan at gold.safeguard.sh/scan can give you a baseline to measure against.
Quick check
What is a good dismissal rate?
There is no standard figure. Compare your own trend and aim to lower the rate for the noisiest rules while keeping real fixes steady.
Can we measure fatigue without a tool export?
Roughly, by sampling 30 recent findings by hand. Label them and count. It gives a starting point.
Last reviewed: 19 October 2026.
