For an alert that reaches your phone, spend the first five minutes on five checks: what is affected, is it exposed, is it reachable in your code, is there a fix, and who owns it. If you cannot answer the first two quickly, escalate rather than guess. The aim is a sound decision, not a full investigation.
The checklist
1. What is affected. Name the package or service, the version in use, and which project depends on it. If the alert does not say, that is itself a finding about your tooling.
2. Is it exposed. Does the affected component sit on a path that outsiders can reach, or is it a build time tool, a test dependency or an internal script? Production internet facing code gets priority.
3. Is it reachable. Does your code actually call the vulnerable function? Reachability analysis answers this with a call path. Without that evidence, assume reachable for anything exposed and critical.
4. Is a fix available. A patched version, a configuration workaround, or a fix pull request already open. If a fix exists and the change is small, the work is a review and a deploy, not a crisis.
5. Who owns it. Every alert should end with a name. If nobody owns the service, assign it to whoever is on call and fix the ownership map on Monday.
Severity is a starting point
A score tells you how bad a flaw can be in general. It does not tell you how bad it is in your environment. A medium score on an exposed, reachable path in an authentication library can matter more than a critical score in a package your code never loads. Use the score to sort, and the checklist to decide.
Signals that justify waking someone
- Evidence of active exploitation reported by a reputable source.
- A reachable path from an internet facing entry point.
- Sensitive data or credentials in the blast radius.
- No workaround and no fix, with the component in production.
If none of those apply, a clear ticket with an owner and a date is usually the right outcome.
Signals that can wait
- Dev only dependencies with no production path.
- Findings in code that is not deployed.
- Alerts that duplicate one you have already handled.
Keep the loop short
Write the decision where the team will see it, in the ticket or the chat thread, in two lines: what you found and what you chose. Include a recheck date for any deferral.
Reduce alert fatigue before it bites
Most bad on call nights start with too many alerts. Tune routing so that phone notifications go only for items that meet your wake criteria, and send the rest to a daily digest. Review the rules every quarter.
The Safeguard iOS app lists alerts and findings review among its phone features, and policies and gates in the platform are where you encode what should block a release in the first place. That keeps tonight's alert list shorter tomorrow.
Quick check
Should every critical severity alert wake someone?
No. Severity is general. Wake someone when the flaw is exposed, reachable or being exploited, and there is no quick mitigation.
Sources
Last reviewed: 19 October 2026.
