How to Assess the Blast Radius of a Code Change

A code change can be small and still affect a large part of a production system.

A two line change to a shared library can reach dozens of services. A large pull request isolated to an internal tool might affect almost nothing outside that tool.

This is why the number of changed lines is not enough to understand the potential impact of a change. Blast radius is about what could be affected if a change behaves differently than expected. Assessing it before merge gives engineers another way to understand the production implications of a change.

What is the blast radius of a code change?

It can include:

• Directly modified components
• Dependent services
• Shared libraries
• APIs
• Databases
• Infrastructure
• Internal users
• External users
• Business critical workflows

The blast radius is not necessarily the same as the number of files changed. Consider two changes:

For the broader connection between change scope and production reliability, see What Is Production Reliability in Software Engineering?.

Why blast radius matters

Understanding blast radius helps engineers decide how much attention a change deserves.

A change affecting one isolated component may need normal review and testing. A change affecting a shared production dependency may justify additional verification or a more controlled deployment.

This does not mean every change with a large blast radius should be blocked. It means the potential impact should be visible before the change reaches production.

Step 1: Identify what changed

Start with the pull request itself. Look at:

• Files changed
• Components modified
• Functions changed
• APIs changed
• Configuration changes
• Database changes
• Infrastructure changes
• Shared code

Ask:

What part of the system is actually changing?

The answer becomes the starting point for mapping the potential impact.

Step 2: Map dependencies

Next, determine what depends on the changed component.

Useful dependency relationships can include:

• Package dependencies
• Module imports
• Service to service calls
• API consumers
• Database relationships
• Shared infrastructure
• Event streams
• Queues

The more downstream relationships a component has, the more carefully its potential impact should be considered.

Step 3: Identify direct and indirect impact

Not every affected component is directly modified. Separate the impact into two levels.

Step 4: Look at production usage

Dependency relationships tell you what could be affected. Production usage helps show what actually matters. Consider:

• Request volume
• Number of services using the component
• Customer facing paths
• Business critical workflows
• Geographic or regional usage
• Internal versus external consumers

A component used by ten internal development tools does not necessarily have the same production significance as one used by ten customer facing services.

Step 5: Check historical incidents

Look at whether the affected components have caused problems before. Useful questions include:

• Has this component appeared in previous incidents?
• Have similar changes caused outages?
• Has the dependency been unstable?
• Have previous deployments required rollback?
• Are there recurring failure patterns?

Historical incidents do not mean that the current change will fail. They provide context that should not be ignored when evaluating the change.

Step 6: Look at recent changes

Recent change activity can provide another signal. Check:

• How frequently the component changes
• Recent deployments
• Recent refactoring
• Multiple concurrent changes
• Recent ownership changes
• Changes to related dependencies

A component undergoing several changes at once can be harder to reason about than a stable component. This becomes more useful when combined with the actual scope and dependencies of the current change.

Step 7: Consider production behavior

Current runtime behavior can also affect the assessment. Look at relevant error rates, latency, resource usage, dependency failures, runtime anomalies, and recent alerts.

For example, changing a heavily used component that is already showing elevated error rates may warrant additional investigation.

Observability provides much of this evidence. See Production Reliability vs Observability for how runtime signals fit into broader production reliability analysis.

Step 8: Consider the type of change

Not all changes have the same potential impact. Pay particular attention to changes involving:

The actual significance depends on the architecture and production usage of the system.

Step 9: Consider deployment conditions

Blast radius is not only about what could be affected. It is also about how the change reaches production. Consider whether the change will use:

• Feature flags
• Canary deployment
• Gradual rollout
• Regional rollout
• Easy rollback
• Automated rollback
• Manual rollback

For example, a change affecting 20 services but released gradually may have different operational exposure from the same change deployed everywhere immediately.

Deployment controls can therefore reduce the practical exposure of a change even when its theoretical blast radius is large.

A simple blast radius model

You can think about the assessment as several layers:

Blast radius vs change size

One common mistake is treating lines of code as a proxy for production impact. They are not equivalent. For example:

The table is illustrative rather than a universal classification. The architecture and usage of the system determine the actual impact.

Blast radius and testing

Once the potential blast radius is understood, it can inform testing.

A change affecting one isolated component might require focused tests. A change affecting a shared dependency may justify broader verification. That could mean integration tests, end to end tests, load tests, regression tests, additional staging verification, or canary testing.

The point is not to test everything equally. It is to align verification with the potential impact of the change.

For a broader pre deployment process, see How to Assess Production Reliability Before Deployment.

Blast radius and pre merge analysis

Blast radius is one part of pre merge reliability analysis. A useful workflow is:

• Pull request: what changed?
• What depends on it?
• Who uses those dependencies?
• What production paths are affected?
• What is the potential blast radius?
• What evidence do we have?
• Decision: what action is appropriate?

This fits into the broader workflow described in Pre Merge Reliability Analysis: How to Evaluate a Change Before Merge.

What should you do when the blast radius is large?

A large blast radius is not automatically a reason to reject a change. Instead, it can trigger additional questions:

• Is the change sufficiently tested?
• Are the affected dependencies understood?
• Can the deployment be gradual?
• Is rollback straightforward?
• Is monitoring available?
• Does the team understand the potential failure modes?
• Is there a way to reduce the scope?

Possible actions include adding tests, splitting the change, adding a feature flag, deploying gradually, adding monitoring, requesting additional review, investigating dependencies, and improving rollback controls.

The appropriate response depends on the change and the team's reliability requirements.

Where static analysis fits

Static analysis can help identify code level problems, but it does not necessarily reveal the full production reach of a change.

A static analyzer may identify a problematic API usage. It may not know that the affected function is called by a large number of production services or sits on a critical customer workflow.

That is why blast radius assessment can complement static analysis. See Production Reliability vs Static Analysis.

Production Reliability Index

Tomosu uses the Production Reliability Index (PRI) to bring multiple reliability signals into a broader view of changes and production systems. The platform describes PRI as a master score built from seven sub indices:

• Fragility Index
• Drift Index
• Governance Compliance
• Runtime Signals
• Code Volatility
• Deployment Velocity
• Escalation Index

These signals are calibrated to the organization and used across development, pre merge, and production.

Blast radius is therefore one piece of the broader reliability context around a change rather than a standalone score.

Try the Production Reliability Index →

Practical blast radius checklist

Before merging a change, ask:

The main idea

• A pull request tells you what changed.
• A dependency graph tells you what the change can reach.
• Production usage tells you what those dependencies actually affect.
• Deployment conditions tell you how much of that potential impact is exposed at once.

That context can then feed into the broader production reliability assessment before the change is merged. For the next step, see How to Assess Production Reliability Before Deployment.

Frequently asked questions

A pull request tells you what changed. Blast radius tells you where it can travel. Tomosu's Production Reliability Index brings that reach together with dependencies, runtime signals, and history before the change merges. Try the Production Reliability Index →