Service Topology
See your services the way they actually run. Service Topology draws the live map of what depends on what — business service, application, logical component, server, storage, and network laid out in distinct layers — so when a node turns red you can trace the blast radius down to the configuration item at fault, and follow the dependency chain back up to every service and user affected. The map is rendered from the shared configuration data, so it reflects the current state of your estate rather than a diagram someone last updated months ago.
Built for the way service topology should work
See your services the way they actually run. Service Topology draws the live map of what depends on what — business service, application, logical component, server, storage, and network laid out in distinct layers — so when a node turns red you can trace the blast radius down to the configuration item at fault, and follow the dependency chain back up to every service and user affected. The map is rendered from the shared configuration data, so it reflects the current state of your estate rather than a diagram someone last updated months ago.
The module reads directly from the same configuration items, relationships, and relationship types (depends-on, runs-on, hosts, uses) maintained in Service Configuration Management and kept current by Discovery. Because there is no separate copy of the graph, every node on the map is the live record: click a service and you jump straight to its open incidents, problems, pending changes, related agreements, and asset details without losing context. Direction-aware traversal lets you query upstream impact and downstream dependency separately, find the shortest path between any two CIs, and flag single points of failure that have no alternate route.
Service Topology is where the rest of the platform comes to understand scope. Before a change ships, it previews the impact — listing the services, dependencies, and users in scope so Change Management and the relevant CAB or advisory group can weigh risk against an accurate picture rather than a guess. When an incident opens, the impact ring shows how many users sit behind the affected node, helping Incident Management prioritize, and Problem Management uses the same path-finding to isolate root cause. Health overlays pull live status onto the map so degradations surface visually, on the graph, instead of in a postmortem.
Everything runs on the one shared data model that connects all 29 modules, so the topology, the SLA targets, the contracts, and the spend behind each service are the same records seen from different angles. Saved lens profiles narrow the map to production, to a single team, or to only business-critical services; time travel replays the graph for any past date to show when a CI was added or a dependency changed; and snapshots let you lock a view and share it with stakeholders who never open the console.
- Live service maps
- Dependency visualization
- Impact & blast radius
- Topology exploration
- Health overlays
- Change preview
What you can do with it
Live service maps
Renders services across business, application, logical, infrastructure, and network layers directly from current configuration data, so the map reflects how the estate actually runs rather than a stale diagram.
Blast radius tracing
Walks the dependency graph in both directions from any node to expose every downstream component at risk and every upstream service and user affected when something fails.
Path finding
Selects any two configuration items and lists every dependency path between them, highlighting the shortest route and surfacing single points of failure with no alternate path.
Change impact preview
Computes the services, dependencies, and users in scope for a planned change before it ships, so risk is assessed against an accurate map instead of an estimate.
Health overlays
Pulls live status onto the map so degraded and failing nodes are visible on the graph at a glance, alongside their open incidents and pending changes.
Time travel & snapshots
Replays the topology for any past date to show when CIs and dependencies changed, and locks a current view into a shareable snapshot with comments and highlights.
Why teams adopt it
Faster root cause
Tracing the dependency chain on a live map turns a multi-team hunt into a few clicks, cutting the time between a service turning red and finding the CI behind it.
Safer changes
Seeing the affected services and users before approval lets the CAB catch high-risk scope early, reducing change-induced outages.
Shared scope view
Because the impact ring reads from the same data the whole platform uses, incident, problem, and change teams argue from one accurate picture instead of conflicting spreadsheets.
Visible architectural risk
Automatic single-point-of-failure detection brings fragile dependencies into the open before they cause the next incident, not after.
Where it fits
Major incident triage
When a business service goes down, responders open its node, read the impact ring for affected users, and follow the path to the failing infrastructure component in minutes.
Pre-change risk review
A change owner previews the impact of patching a shared database, sees which services depend on it, and routes the right CAB members in before scheduling the work.
Problem investigation
A problem manager uses path finding between a recurring symptom and suspected components to isolate the shared dependency causing repeat incidents.
Resilience review
An architecture team filters to business-critical services and uses single-point-of-failure flags to build a prioritized list of dependencies that need redundancy.
Common questions
No. Service Topology reads the configuration items and their relationships straight from Service Configuration Management (the CMDB), and Discovery keeps those records current through automated scanning. The map is a live view of that shared data, so you maintain relationships once in the CMDB and the topology updates automatically rather than maintaining a separate diagram.
Part of these solutions
Related modules
See Service Topology in action.
Book a demo and we'll show service topology working alongside the rest of the platform — on one shared data model.