The cost of a false positive is the minutes someone spends deciding it is false, multiplied by how often that happens. With a few inputs you can turn a false positive rate into hours per week and compare it against the hours a tuning project would take.
Inputs you need
- Alerts per week.
- Share that are false positives.
- Average minutes to dismiss one. Measure this from timestamps, or time ten of them.
- Minutes to handle a true one, since it is a separate cost.
Everything below uses made up numbers to show the method.
Baseline
A tool raises 500 alerts per week. Ninety percent are false, so 450 are false and 50 are real. Dismissal takes 5 minutes.
- Dismissal time: 450 times 5 equals 2,250 minutes, about 37.5 hours per week.
That is close to a full time job spent saying no.
After tuning
Suppose tuning cuts the false share to 70 percent while the 50 real alerts still fire. Total alerts then equal 50 divided by 0.3, about 167. False ones number about 117.
- Dismissal time: 117 times 5 equals 585 minutes, about 9.75 hours per week.
- Saved: about 27.75 hours per week.
If the tuning took 40 hours once, it pays back in under two weeks. Even if it took 200 hours it pays back in about seven. The value is in setting that comparison down in numbers before arguing about priorities.
The costs that are not in the formula
The hours above understate the damage.
- Attention decay. People who dismiss 90 percent of alerts start dismissing faster and with less care. A real alert in the pile gets the same two second glance.
- Context switching. Each interruption costs more than its handling time.
- Trust. When developers see that most tickets from a tool are wrong, they stop reading them.
These are hard to put numbers on, so say plainly that your estimate is a lower bound.
Where tuning has the best return
Rank rules or finding types by false alerts times dismissal time. The top few usually account for most of the load. Fix or disable those first, and keep a log so a change can be undone if it hides something real. Work on the 80 percent of noise from five rules before the long tail.
Be careful about tuning on the same data you evaluate on. See testing a detection rule change with a holdout.
Do not forget the recall side
Every tuning step that removes false alerts risks removing true ones. Check what you suppress. A rule that goes quiet is either clean or blind, and the alert count alone cannot tell you which. For the other side of the trade, read precision versus recall for detection thresholds.
Quick check
How do I find the average minutes to dismiss an alert?
Use ticket timestamps for the time between opened and closed as false positive, or time a sample of ten by hand. A rough value is fine for the comparison.
Should I aim for zero false positives?
No. Pushing to zero usually means missing real issues. Aim for a rate your team can handle at the volume you see.
Last reviewed: 19 October 2026.
