Every maintenance window on the core carries the same quiet question: what happens to everything else while this piece is down? Most teams answer it from memory and a diagram — “that site has a second path, I’m fairly sure” — and then find out whether they were right at the worst possible moment. The ones who sleep well have a way to rehearse the failure before they cause it.
The problem with “it should be fine”
Redundancy is easy to design and hard to remember. A network built with two of everything slowly accumulates exceptions: a temporary single-homed site that became permanent, a backup path that was re-routed during an incident and never restored, a link that everyone assumes is redundant because it used to be. None of these show up until the primary is gone — and by then you’re not planning, you’re recovering.
Up/down monitoring won’t warn you either. Everything is green right up to the moment you take the link down, because nothing has failed yet. The risk lives in the structure, not in any counter.
Rehearsing the failure on the map
Failure-impact simulation flips the timing. Instead of learning the blast radius during the outage, you learn it beforehand, on a map built from the network’s real adjacencies. You mark a node or link as down in the simulation and the map shows you the consequences:
- Which sites lose reachability entirely — the ones that depend on the piece you’re about to touch, with nothing behind it.
- Which sites lose redundancy — still up, but now running on a single path, so they’re one more failure away from dark for the duration of your window.
- Where traffic would re-route — the paths that would carry the load instead, so you can check they can actually take it.
Because the simulation runs against the topology the network really has — not the one on the wall — the answer reflects today’s exceptions, not last year’s design intent.
From gamble to plan
That single view changes the shape of the change. A window that looked routine might reveal a site that would go dark, so you stage the work differently or fix the missing path first. A window you were nervous about might turn out to be clean, so you proceed with confidence instead of a held breath. Either way you’ve replaced a guess with a decision, and you can hand the change board evidence rather than reassurance.
The same capability pays off after the fact, too. When you can see how a failure would propagate, you can find the single points of failure you didn’t know you had — the quietly single-homed site, the redundancy that quietly evaporated — and fix them on your schedule instead of during an incident.
Making it routine, not heroic
The teams that get the most from this don’t treat simulation as a special-occasion tool for the scary changes. They run it as a habit. Every window that touches shared infrastructure gets a quick pass: mark the affected pieces down, look at what lights up, attach the result to the change. It takes minutes and it turns the change record into something with actual predictive content — a statement of what the team checked would happen, not just what they intended to do.
Done consistently, it also builds an institutional memory of where the network is fragile. Patterns emerge across windows: the same site keeps showing up as a single point of failure, the same link keeps carrying more re-routed load than feels comfortable. Those aren’t findings you’d stumble on from day-to-day monitoring, because nothing is wrong yet. They’re the map telling you where tomorrow’s outage is most likely to start — early enough that fixing it is a planned project rather than a postmortem action item.
See how Phantom builds the live map and runs failures against it on the visualization platform, and how teams use it day to day in network visualization.
Want to rehearse a failure on your own core before the next window? Book a demo.