Blast radius
Also known as Blast radius practice, Blast radius operations
Definition
Blast radius is a reliability concept used to describe a specific condition, control, or decision in the operation of software services.
Understanding Blast radius
Blast radius is a reliability concept used to describe a specific condition, control, or decision in the operation of software services. For example, a team operating a customer-facing API can use blast radius to make a reliability discussion concrete. Responders can identify the affected scope, record the relevant signal, assign an owner, and choose a next action that protects the user journey.
How teams use it
In practice, blast radius should be defined alongside its trigger, time window, population, and expected response. This makes comparisons consistent and keeps later reviews grounded in what was known at the time. For example, a team operating a customer-facing API can use blast radius to make a reliability discussion concrete. Responders can identify the affected scope, record the relevant signal, assign an owner, and choose a next action that protects the user journey. The record should preserve the signal, owner, decision, and outcome so another responder can understand the context without relying on memory. That distinction matters when this concept appears near a deployment, dependency change, or customer report.
Limits and cautions
The term has no useful meaning without service context. Different architectures, traffic patterns, dependencies, and business priorities can produce different thresholds or acceptable outcomes. A dashboard value may support investigation without proving cause, severity, or user harm. Avoid turning blast radius into a proxy for engineering quality without checking its definition, denominator, scope, and user relevance. A control can reduce one failure mode while leaving another untouched, and a healthy aggregate can hide a critical slice.
How Weave relates
Weave can connect blast radius work with engineering ownership, delivery history, and related reliability evidence. It does not operate production systems, replace service telemetry, or claim an outcome that is not directly measured. Teams should keep the operational source of truth close to the service and use engineering context as supporting evidence.
Practical takeaway
Use blast radius as a precise term for a defined operational question. State the owner, evidence source, scope, and expected response so the concept remains actionable during an incident and interpretable during later reliability work.
How this relates to Weave
Weave can connect blast radius work with engineering ownership, delivery history, and related reliability evidence. It does not operate production systems, replace service telemetry, or claim an outcome that is not directly measured. Teams should keep the operational source of truth close to the service and use engineering context as supporting evidence.
Explore Engineering intelligence