Your observability stack tells you what changed and what failed. The gap between those two data points — understanding which change caused which failure — is where most P0 postmortems spend most of their time. Change impact analysis closes that gap before the incident, not after.
Change analysis vs. impact analysis
Change analysis answers: what code changed in this PR? Every version control system does this. You can see the diff, the files touched, the lines modified.
Impact analysis answers: given those changes, which other services are now at risk, and how much? This is the harder question, and it requires knowing the full dependency graph of your system — not the documented version, but the actual version that lives in import statements, API contracts, and live traffic patterns.
Most platform engineering stacks have mature change analysis (git diffs, conventional commits, changelogs). Almost none have mature pre-merge impact analysis. The result is that engineers do impact assessment manually during code review — which is slow, error-prone, and only as good as the reviewer's knowledge of the dependency graph.
Why blast radius is the right metric
The term "blast radius" comes from failure mode analysis in distributed systems. For a given change, the blast radius is the set of services that would be degraded or failed if that change caused a production error in the modified service.
Blast radius has three useful properties as a metric: it is computable from the dependency graph before deployment, it correlates with incident severity more directly than change volume does, and it is a leading indicator rather than a lagging one.
A change to a leaf service with no dependents has a blast radius of 1 — only that service is affected if something goes wrong. A change to a shared authentication service that 14 other services depend on has a blast radius of 15 or more. Those two PRs require fundamentally different levels of review scrutiny, and blast radius makes that difference explicit and automatic.
Where impact analysis fits in the delivery cycle
The most effective place for change impact analysis is the PR check — after the diff is visible but before code review begins. At this point:
- The change is fully specified (the diff is the change)
- No deployment has happened, so rollback is trivial
- A reviewer can look at the blast radius and adjust review depth accordingly
- A high-risk score can trigger additional review requirements or a pre-merge approval gate
Impact analysis applied after deployment — as part of APM or incident investigation — is still valuable, but it arrives too late to prevent the incident. The risk score in the PR check is the pre-merge version of that analysis.
"The incident does not start at 2 AM. It starts when a PR merges without anyone knowing what is downstream."
The metrics that validate whether impact analysis is working
Three metrics measure whether a change impact analysis program is having effect:
P0 incidents attributed to dependency-blind merges. Track incident postmortems and tag any P0 where the root cause involved an undocumented or missed dependency. This number should decrease. If it does not, the graph accuracy needs work.
Review time on high-blast-radius PRs. This often goes up initially — reviewers suddenly realize these changes need more attention than they were getting. Over time it stabilizes as teams adjust norms. If review time on high-risk PRs stays the same as on low-risk PRs, the signal is not being used.
Graph accuracy rate. When an incident does occur, compare the actual propagation path with what the pre-merge blast radius calculation predicted. High accuracy means the graph is real; low accuracy means one of the three data sources (static analysis, API contracts, service mesh traces) is misconfigured or incomplete.
The goal is not to prevent all incidents — that is impossible. The goal is to ensure that when an incident occurs, it is not because someone merged without knowing what was downstream.
What change impact analysis can and cannot tell you
It's worth being specific about the boundaries of what graph-based impact analysis provides. This matters for setting realistic expectations with stakeholders who may conflate "impact analysis" with "guaranteed no incidents."
Change impact analysis tells you: which services are in the blast radius of a given change, what the historical risk profile of those service relationships is, and whether the change volume and API surface area of the PR are consistent with previous high-risk merges. It gives you a risk estimate, not a correctness guarantee.
What it does not tell you: whether the code change itself is correct, whether the tests are adequate, whether the performance characteristics are acceptable, or whether there are race conditions in the changed logic. Those are code review concerns, not impact analysis concerns. Impact analysis tells you who needs to be in the review, not what they should look for.
We're not saying impact analysis is sufficient for a high-reliability deploy culture. We're saying it fills the specific gap between "we know what changed" and "we know what might break" — a gap that pure code review doesn't close, because code reviewers are optimizing for code correctness, not for downstream dependency knowledge.
Adoption patterns across team structures
The teams that adopt change impact analysis most smoothly tend to be those where the platform engineering function is already treated as a product team serving internal developers. They introduce risk scores as a new piece of information in the PR interface — not as a new gate, initially — and let the signal build credibility over a few weeks before enabling enforcement.
The teams that struggle tend to be those where the platform team and product engineering teams have friction over process ownership. Introducing a risk gate without buy-in from product engineering leads feels like the platform team adding overhead to delivery. The fix is not process redesign; it's starting with the high-severity incident data and letting engineers see whether their recent incidents would have been flagged by the pre-merge score. That conversation tends to shift the perception from "overhead" to "I wish we'd had this in the incident last month."