blast radius
jargoncloudops culturesecurity
How far the damage spreads when one component fails or is compromised.
Blast radius is a design lens: architect so a single failure, a bad deploy, a breached account, is contained rather than cascading. Minimizing it, through isolation, segmentation, and limits, is why changes are staged and privileges are scoped.
Blast radius is the question you should ask before a change, not during the incident review afterwards: if this goes wrong, what else goes with it? A configuration that touches one virtual server has a small radius. One that touches a shared profile, a route domain, or a certificate used by forty services has a large one, and the size is rarely visible from the change ticket.
The reason it matters more than change complexity is that simple changes with large radii cause the worst outages. Editing one line in a shared object is trivially easy and can take down everything that references it, while a complicated but well-isolated change fails safely. Difficulty and consequence are independent variables, and people routinely conflate them.
Practically, thinking in blast radius changes what you do rather than just how nervous you feel. It drives whether you stage the change, whether you need a maintenance window, whether rollback is one command or a restore, and whether anybody outside your team needs to know. Those decisions should follow from the radius, not from the calendar.
Also known as: blast-radius