Direction is the first decision
A dependency graph contains two different questions. "What do I need to work?" follows dependencies upstream. "What breaks if I fail?" follows dependents downstream. Mixing the two produces a diagram that looks like a blast radius but answers neither question.
For incident response, the downstream set is the useful one. If payments-gateway fails, the services that call it are affected. The services it calls are a separate dependency problem.
Hop depth changes the response
A direct dependent fails immediately. A service two hops away may degrade or may absorb the failure with a queue. Three hops away is often a monitoring concern rather than an incident. Grouping by depth lets an on-call engineer decide where to look first instead of reading a flat list of 40 names.
In the sample company, payments-gateway has eight downstream services across three hops. The direct set includes checkout-api, dispute-service, mobile-bff, config-service, notifications and webhook-relay. fraud-scoring and recommendation appear at the next hops.
The edge with no owner
A cascade is only actionable if each node has an owner. The sample cascade contains config-service, which has no OWNED_BY edge and no on-call engineer. That is more important than the total count: one unowned service can turn a contained failure into a long incident.
Blast-radius reports should carry ownership coverage as a first-class number. "Eight services, one unowned" is a better summary than "eight services".
Keep the map honest
Dependency edges age. A service that was synchronous last quarter may be behind a queue now. Record how each edge was discovered, when it was last verified, and whether it is synchronous or asynchronous. An unverified edge is a hypothesis, and the report should say so.
The cheapest validation is an incident review: compare the services that actually degraded with the set the graph predicted. Add the missing edge and correct the stale one while the details are fresh.
Worked example: the payments cascade
Question: "What breaks if payments-gateway goes down?" The graph returns eight services across three hops, with the owning team and on-call for each. It flags config-service as unowned and notification-worker as a two-hop dependency through checkout-api.
The answer is not a list of every service in the company. It is a bounded, dated traversal that an engineer can compare with the incident channel. If the channel shows a service that is not in the set, the graph has a missing edge.