Blast Radius Simulator

Last Updated: September 28, 2026
Estimated Reading Time: 6 minutes

Overview

The Blast Radius Simulator shows the CIs and services that can be affected if a CI fails or changes. Use it for change review, incident triage, and resilience planning.

CMDBx calculates the result with deterministic, versioned relationship rules. AI does not decide which CIs are affected. The same CI and the same topology always give the same result.

How It Works

  1. CMDBx starts at the CI that you select.
  2. CMDBx follows outage-propagating relationships to the CIs and services that depend on that CI. Relationship rules decide which relationship types carry impact.
  3. CMDBx continues level by level until it reaches the depth that you set, or until the topology ends.
  4. CMDBx records every path, every relationship that it excluded, alternate routes, and modeled single points of failure.
  5. CMDBx saves the result, so that you can export the same evidence later.

The analysis always follows impact from the failed CI to its dependents. To review what a CI can reach in both directions, use Exposure Analysis.

How to Run a Simulation

  1. Go to Dependency Map.
  2. Find the CI. Use search or the map.
  3. Right-click the CI.
  4. Select Simulate Outage.
  5. Review the results in the side panel.

To change the depth, use the depth control and run the simulation again. The default depth is 5. Outage analysis supports depth 1 to 9.

Start with depth 3 to 5. A higher depth gives a larger result that is harder to review.

Results

Impact Summary

  • Direct impacts are one relationship level from the selected CI.
  • Indirect impacts are reached through more levels.
  • Important services in the result are listed separately.

Ranked Results

Each impacted CI shows:

  • its risk: a model-based priority, not a probability of an outage
  • the path that connects it to the selected CI
  • alternate modeled routes, when they exist
  • whether it is a modeled bottleneck or depends on one

Evidence Confidence and Limitations

The side panel shows the environment, the analysis time, the depth, and the limitations of the evidence. Overall Evidence Confidence is Low when:

  • the topology is stale, for example when the last completed sync is old
  • CI details are missing
  • a depth, node, relationship, or time limit stopped the analysis early

Confidence describes the quality of the evidence. Risk describes priority. A high risk score with Low confidence means that the CMDB data limits the answer. A modeled alternate route does not prove that failover was tested.

Evidence Details

Open Blast Radius Evidence to see:

  • Technical Path Evidence: the relationships that CMDBx followed
  • Included and Excluded relationships, with the reason for each exclusion
  • Analysis Metadata: the rule version, the limits, and the data freshness

How to Export Results

  1. Run the simulation.
  2. Select Export PDF or Export CSV.

The PDF is a formatted report for a change request or CAB review. The CSV contains the CI, service, relationship, risk, and path evidence. CMDBx creates both exports from the saved result. An export does not run the simulation again.

How to Use Simulations

For Change Management

  1. Run the simulation on the CI that will change.
  2. Review the important services and the modeled bottlenecks.
  3. Check the evidence confidence.
  4. Export the PDF and attach it to the change request.

When a change request has more than one affected CI, use Change Impact Analysis. It analyzes all affected CIs as one graph.

For Incident Response

  1. Run the simulation on the failed CI.
  2. Review the direct impacts first.
  3. Use the paths to confirm which services depend on the failed CI.

For Resilience Reviews

  1. Simulate the failure of critical infrastructure.
  2. Review the modeled single points of failure.
  3. Check whether alternate routes exist.
  4. Plan work to remove bottlenecks or to model real redundancy.

Best Practices

  • Run a simulation before every major change.
  • Check the evidence confidence before you rely on a result.
  • Run a sync before important reviews, so that the topology is fresh.
  • Export the result for the audit trail.
  • Do not use dev or test CIs to assess production changes.

Related Articles