0%
The Blast-Radius Playbook (Use Every Time)
10 min
The blast-radius playbook
Print this. Use it on every triage call.
The seven dimensions
- Users affected — absolute count and percent of active users
- Segment value — enterprise seats, paying vs free, contractual SLAs
- Workaround quality — full, partial, painful, or none
- Money / data / safety / compliance — any hit here escalates attention
- Detectability — silent failures compound; loud ones get tickets
- Release proximity — ship train this week vs next quarter
- Mitigation cost — can we contain cheaply while a durable fix lands?
Severity bands (working definitions)
| Band | Meaning | Examples |
|---|---|---|
| Critical | Core journey broken for many, or money/data/safety at risk | Checkout fails, auth down, data leak |
| Major | Significant friction or partial outage | 2% login fail, broken search for a cohort |
| Minor | Limited impact, clear workaround | Slow admin export with filter workaround |
| Trivial | Polish / copy / low-risk cosmetic | Typo off critical path |
Priority bands (working definitions)
| Band | Meaning |
|---|---|
| P0 | Drop / stop-ship / contain now |
| P1 | This sprint / before release if feasible |
| P2 | Scheduled soon; not sole release blocker |
| P3 | Backlog polish when capacity allows |
Story: Under-labeling money risk
Dev marked double-submit charges as “edge case, rare.” QA left severity at Minor because repro needed slow 3DS.
Week later: refunds stacked; trust tickets rose. The bug was always high business severity — rarity only delayed detection.
Pro Tip: Rarity reduces frequency, not integrity risk. Money and identity bugs stay severe until proven otherwise.
Anti-patterns
- Everything-P0 to please Slack
- Ranking by who yelled last
- Ignoring internal tools that can delete users irreversibly
- Treating a11y-on-checkout as “just design”
Checklist (copy into tickets)
- Users / %
- Segment / contract
- Workaround
- Money / data / safety / legal
- Silent vs loud
- Release impact
- Containment option named