Before a new alert is allowed to page a human, ask five questions: could you ever ignore it, does it prove users or data are affected, can you act on it, is the action urgent, and could a machine do the action. If the answers are weak, it belongs in a queue or a dashboard, not on a pager.
The five questions
Google's SRE book lists these when discussing alert rules. They translate well to security detections.
- Will I ever be able to ignore this alert, knowing it is benign? If yes, it is noise by design.
- Does this alert definitely indicate that people or data are being negatively affected? A suspicious signal is not the same as harm.
- Can I take action in response? A page with no available action is only stress.
- Is that action urgent, or could it wait until morning? Most can.
- Could the action be safely automated? If so, automate it and page only on failure.
A bonus question from the same list: are other people getting paged for the same issue? Duplicate pages train people to assume someone else has it.
Applying them to a security alert
Take "new admin account created outside business hours". Run the questions.
- It might be benign, for example a planned change. That is a yes to question one, which is a warning.
- Harm is not certain. Question two is a no.
- You can act, by checking the change ticket. Question three is a yes.
- Urgency depends on the account's reach. Maybe urgent for production, not for a test tenant.
- The check against change tickets could be automated. Question five suggests doing that first.
The result: automate the ticket lookup, and page only when no matching change exists on a production system.
Where non-urgent alerts should go
The same chapter says email alerts have limited value and are easily swamped, and recommends a dashboard for subcritical problems. A daily queue with an owner works equally well. The key is that someone is accountable for looking.
Review them again
Alerts rot. Review page frequency regularly, the book suggests quarterly, and delete or demote anything that has not led to action.
Make the questions part of review
Add the five questions as a checklist in your detection pull request template. The author answers them in writing, and the reviewer can challenge the weak answers. That turns paging into a deliberate choice instead of a default.
Revisit older alerts with the same list. Many alerts were created in a hurry after an incident and never questioned again. A one hour review of the ten noisiest, applying these questions, often removes a large share of the noise without losing any real coverage.
Quick check
Should every high severity alert page someone?
No. Severity describes potential impact, not the need for a human to act right now. Page on confirmed, urgent, actionable problems.
Sources
Last reviewed: 19 October 2026.
