How to Map Blast Radius During an Incident: 5 Tool Classes Compared

Sixty-eight percent of organizations lose more than $300,000 for every hour a major incident runs, and 8% lose more than $1 million an hour, according to PagerDuty's 2026 State of AI-First Operations Report. That clock starts when the first alert fires. Yet the first 15 minutes of most incidents aren't spent fixing anything. They're spent working out what the failing service touches, what changed, and who to page.

If your service dependency map lives in three engineers' heads, those 15 minutes stretch. This guide covers how to map blast radius during an incident from that starting point. It walks through the four ingredients a real blast-radius map needs, the five tool classes that each hold a piece of it, a side-by-side comparison, and a runbook for the first 15 minutes. It's the incident-specific version of the pattern in our post on searching Slack, GitHub, and Jira in one query.

Our service dependency map lives in a few engineers' heads. Can AI tools map blast radius during an incident?#

Yes, but no single tool class holds the whole picture, and buying one more dashboard is how teams end up with the same gap in a new tab. A blast-radius map has four ingredients: the dependency graph, what changed recently across every repo that touches the failing service, who owns each piece, and whether this failure has happened before.

In almost every organization those live in four systems: the graph in a catalog or APM tool, the changes in GitHub, ownership in CODEOWNERS or someone's memory, and history in a postmortem nobody has reopened.

The problem is getting harder. Sonar's 2026 State of Code Developer Survey of more than 1,100 developers found AI now accounts for 42% of all committed code, 96% of developers don't fully trust that code to be functionally correct, and only 48% always check it before committing. More code ships faster, and each change carries less human context with it.

During incidents we have 140 people in a Slack channel trying to figure out who touched what. What tools shortcut this?#

A 140-person incident channel is a coordination failure, not a monitoring failure. incident.io's 2026 breakdown of incident response tooling puts the cost at "12+ minutes per incident you spend assembling the team before troubleshooting even starts." That's a real slice of the median 101-minute resolution time StackGen measured across 80,743 incidents at 360 companies in its State of Enterprise Reliability 2026. Only 34.9% of those incidents resolved inside the first hour.

The channel gets big because nobody can answer "who touched the thing that broke" from one place. A catalog knows who owns the service, an APM tool knows what it calls, a ticket says what shipped last week, and one person remembers the last time it fell over. So the channel becomes the join.

Amazon hit this pattern in March 2026. Internal documents reviewed by the Financial Times tied a "trend of incidents" with a "high blast radius" to "Gen-AI assisted changes," as Tessl reported. Junior and mid-level engineers there now need senior sign-off to push AI-assisted code. Our Copilot Autofix at Snowflake write-up is another example of a change shipping without blast-radius context.

500 services built over 25 years: how do we map blast radius when something breaks?#

At that scale the map decays faster than anyone redraws it. Datadog's State of DevSecOps 2026 found the median dependency sits 278 days behind its latest major version, up from 215 days a year earlier, and 87% of organizations run at least one exploitable vulnerability, affecting about 40% of services. The ownership map goes stale too: 25 years of reorgs leave CODEOWNERS files pointing at teams that no longer exist.

A static dependency graph still helps. But a graph tells you fourteen services call the notifications API. It says nothing about which of those calls are dead, what was rewritten last quarter, or that the same outage happened in 2023 with the fix in a Slack thread. Our post on context engines vs. knowledge graphs covers why a graph on its own stops short there.

Ben Johnson, the sole architect at Subsplash, describes what the ownership side of this feels like at scale:

I'm the only architect at Subsplash, supporting dozens of engineers and over a thousand actively maintained repos. When people ask me questions, I don't want to leave them waiting. Unblocked is how our team closes that gap.

Ben Johnson — Software Architect, Subsplash

At 500 services, "ask the architect" is a single point of failure. The map has to live somewhere queryable.

Which tools hold the pieces of a blast radius map?#

Five tool classes, each holding a different piece. Most engineering organizations already run three or four of them: a catalog that's half filled in, an APM tool, an incident tool, and GitHub. None of them holds all four ingredients, so the join happens in someone's head at 2 a.m. Here's what each class gives you, and what it's missing.

Service catalogs: the ownership and topology layer#

Backstage, Cortex, and OpsLevel. Backstage's software catalog tracks "ownership and metadata for all the software in your ecosystem," sourced from YAML files kept next to the code and refreshed when changes merge. Cortex says it builds and maintains the dependency graph automatically so teams "can see the blast radius of a change before they make it." OpsLevel auto-discovers services from repos and third-party tools and fills gaps with AI-generated service descriptions.

What you get: a queryable record of who owns what and what depends on what, usually current if teams keep it that way. What's missing: a catalog is a snapshot. It doesn't know what changed an hour ago in a repo outside its scope, and it doesn't know whether this exact failure happened before. It holds the ownership ingredient and, at best, the topology ingredient.

Observability dependency maps: the "what's connected right now" layer#

Datadog's Catalog, Dynatrace Smartscape, and Honeycomb's Service Map. These build topology from live traffic, with no wiki page to keep current. Datadog's Catalog builds its dependency graph from APM telemetry and surfaces on-call, Slack, and repo links next to it. Dynatrace Smartscape auto-discovers "all the topological dependencies in your infrastructure, processes, and services" from monitoring data and keeps 72 hours of topology history. Honeycomb's Service Map draws service-to-service edges from the trace data you send it, each edge standing for at least one observed call from caller to callee in the selected time range.

What you get: the live dependency graph, at a fidelity no hand-maintained catalog matches. What's missing: it's topology only. A trace tells you the checkout service calls the pricing service ten thousand times a minute. It doesn't tell you who owns pricing, what shipped to it yesterday, or that it fell over the same way in March.

Incident tooling: the coordination and timeline layer#

incident.io, Rootly, and PagerDuty. These own the incident itself: who's on call, the timeline, the postmortem. PagerDuty's service dependencies feature shows connected services, their status, open incidents, and on-call responders on the incident page. The dependencies themselves are added by hand or suggested from past incident patterns.

That's the tell for the whole class. Incident tools mostly consume a dependency map rather than build one. They're where the map gets used, and they hold the history ingredient (postmortems) and part of the ownership ingredient (who's on call right now). For wiring PagerDuty and GitHub into a coding agent so it can pull that timeline directly, see our PagerDuty MCP setup guide. This post stays one level up: which class holds which piece.

GitHub blame and CODEOWNERS: the free, always-there, incomplete layer#

Every team has this layer already. git blame tells you who last touched a file, and CODEOWNERS routes reviews to whoever the file says owns the path. The catch is in GitHub's own docs: "If you specify a user or team that doesn't exist or has insufficient access, a code owner will not be assigned." The last matching pattern also takes precedence, so a broad catch-all can override a specific owner without anyone noticing.

What you get: a first guess at who to page, at zero setup cost. What's missing: CODEOWNERS rots with every reorg and departure, and blame only shows who changed this file. It says nothing about which of your 500 services that change reached. It covers ownership partially, and recent changes one repo at a time.

A context engine: joins the pieces into one query#

This is the class Unblocked belongs to. A context engine connects code history, Slack, tickets, docs, and past incidents. Ask it "what changed in anything that calls the pricing service in the last 24 hours, who owns it, and has this happened before?" and it returns a synthesized answer that cites the PR, the Slack thread, and the past incident it drew on. It joins code history, Slack, tickets, and past incidents into one cited answer instead of four browser tabs.

Since Unblocked's Datadog and Sentry integrations landed, incident data, logs, and APM context sit next to the code and conversation history in the same query. The "what's connected" ingredient arrives with the "who owns it" and "has this happened before" ingredients. Institutional memory across Slack, Jira, Notion, and Confluence is what makes the history piece work; the postmortem nobody re-reads is still in there.

What's missing: coverage. A context engine only joins the sources you've connected. If your dependency graph lives in a catalog it can't see, that piece stays out of the answer.

How do these tool classes compare?#

The tables below map each class to the four ingredients. Read them as a coverage grid rather than a ranking. Most teams should run a catalog, an observability map, and incident tooling regardless of what else they buy. The open question is what joins them.

The same five classes, scored against the four ingredients:

Citations are the point of the last row. Stack Overflow's 2026 analysis of its survey data found more than 84% of developers use or plan to use AI tools while only 29% trust their accuracy, down 11 points in a year. An uncited AI answer at 2 a.m. is one more thing to verify. An answer that links the PR is a lead.

Frequently asked questions#

What's the difference between a service dependency map and blast radius mapping?#

A dependency map is topology: what calls what, either static (a catalog) or live (traces). Blast radius applies that topology to one active failure and adds three more things: what changed, who owns it, and whether it has happened before. Dynatrace, for example, keeps 72 hours of topology history, which is a map, and still can't tell you who to page.

Can Backstage or Cortex show blast radius during an incident, or only after?#

Mostly on demand. Both hold ownership and topology, and Cortex says its automatically maintained graph lets teams see a change's blast radius before making it. Neither correlates live incident telemetry or past postmortems on its own. During an incident they answer "who owns this and what is it wired to," and you still need another source for what changed and what happened last time.

Does GitHub CODEOWNERS tell you who to page?#

It gives you a first guess. GitHub's docs state that an owner who doesn't exist or lacks write access is skipped without an error, and that the last matching pattern wins. After a few reorgs, a CODEOWNERS file can name a team that dissolved two years ago. Cross-check against who is on call right now in your incident tool before paging anyone.

How does a context engine map blast radius differently than a service catalog?#

A catalog holds the ownership and dependency record that teams maintain by hand or by import. A context engine reads across every source it's connected to: git history, Slack, tickets, incident tools, docs. Ask it what changed near the failing service and who owns it. It returns an answer citing the PR and thread it drew from, plus the last incident that looked like this one.

What do you actually do in the first 15 minutes of an incident?#

Build the map before anyone touches a fix. StackGen's 2026 dataset says only 34.9% of incidents resolve inside the first hour, and the average repeat-incident rate across the 342 companies with enough history to measure was 21%. Both numbers argue for the same runbook, in this order.

1. Pull the dependency graph for the failing service. Use whichever source is current: the observability map if the service is instrumented, the catalog if it isn't. Post upstream and downstream in the incident channel so nobody re-derives it.
2. Check what changed in the last 24 hours across every repo that touches it. Include config, infrastructure, and feature-flag repos, and don't stop at the repo someone remembers. Blame on one file misses the change that mattered.
3. Identify owners, then cross-check against who is on call right now. CODEOWNERS and the catalog give you a name. The incident tool tells you whether that person is awake. Page whoever the on-call schedule shows, even if the file says someone else.
4. Check whether this has happened before. Search postmortems, the incident tool, and Slack for the service name and the error signature. One in five incidents is a repeat, and the fix may already be written down.

With a context engine connected to those sources, steps 2 through 4 collapse into one question with cited answers. Without one, assign each step to a different person in the channel and have them post findings in a single thread. Either way, the war room shrinks, because the people who "might know one piece" are no longer the only place the piece lives.

Build the map before you need it#

The four ingredients already exist somewhere in your tools. The catalog has ownership, the APM tool has topology, GitHub has the changes, and the incident tool has the history. What's missing in most organizations is the join, so the 2 a.m. Slack channel does the joining by hand, 140 people at a time, at $300,000 an hour.

Wire the join before the next page. Concretely: make sure every service that can page a human has a current owner in the catalog. Check that the observability map covers those services. Put postmortems somewhere searchable, and out of the slide deck. Then connect those sources to something that can answer across them. That is the job of the context engine for engineering, and it's the same move as giving agents your Slack, Jira, and Confluence knowledge, applied to the moment it matters most. If you want to see what mapping blast radius during an incident looks like when the sources are already joined, try Unblocked against your own repos, Slack, and incident history.