The Configuration Management Database (CMDB) models every configuration item (CI) your infrastructure is made of, and the relationships between them. It is the graph everything else in the platform reads from — cascade auto-escalation, major-incident detection, and change risk context all trace back to this module.
CI model
Configuration items carry a status, environment, criticality, ownership, and technical fields (IP, FQDN, location, vendor), plus free-form attributes. Relationships are modeled as parent-child links with a relationship type: parent is the dependent thing, child is what it depends on. A few relationship types are available (depends on, uses, hosts, hosted on, runs on, connected to, contains) so you can describe a link the way it actually reads — "this rack contains these servers," say — but they all feed the exact same blast-radius calculation underneath. There's no separate "containment hierarchy" distinct from the dependency graph; the relationship type is for readability, not a different traversal.
Business services
Business services have a tier (1 = mission-critical, 2 = business-important, 3 = supporting) and can nest under a parent service. CIs map to services many-to-many. Each service's health — operational, degraded, outage, or maintenance — is rolled up automatically from incident priority across its mapped CIs.
Managing business services (Service Map)
From Service Map, click + New Service to define one — name, description, criticality, tier, an optional parent service to nest it under, and an optional link to a Service Catalog item. Map CIs to it from the service's own CIs tab, picking a role for each (application, database, load balancer, and similar). A completeness check flags CIs related to ones you've already mapped but not themselves mapped in, with a one-click Add to close the gap.
The service's Cost tab rolls up everything Asset Management knows about the CIs mapped to it — asset purchase cost, current book value, software license cost, and maintenance contract cost — into a single total cost of ownership figure, with a flag if the mapped assets span more than one currency.
What "blast radius" means
Following a CI's parent-to-child links surfaces its upstream dependencies (what it depends on). Following child-to-parent links surfaces its downstream dependents — this is blast radius: who breaks if this CI breaks. That downstream traversal is exactly what cascade-escalation logic consumes to count affected CIs and incidents.
Views available
- Full topology graph of the environment.
- Downstream blast-radius view for a given CI, with configurable traversal depth (default 5 hops).
- A bidirectional context graph (3 hops), including active incidents and recent changes touching those CIs.
- A plain-text topology summary formatted for AI-agent context.
Browsing a configuration item
Open CMDB, use the search bar or a CI-class filter (Server, Network Device, and so on) to find what you're looking for, then open it to see its attributes, its upstream/downstream relationships, and the recent incidents and changes that touched it.
Reading the context graph
The same color legend applies everywhere the graph appears — on an incident's Context Graph tab, and in the CMDB's own topology view:
- Red border — the CI directly involved in the incident you opened the graph from.
- Red fill — another CI currently in its own active incident.
- Amber — a CI with a correlated change in the incident window.
- Grey — a dependency CI that is currently healthy.
Pan by dragging, zoom with the scroll wheel, and hover any node for its name, class, environment, and a signal summary.
Example
An alert fires for a storage array, but its Context Graph shows nothing — the CI was never added to the CMDB, so its blast radius is invisible. The on-call engineer investigates manually using MELT logs filtered by hostname, resolves the incident, and flags the CMDB gap to an admin so the array gets added before the next incident touches it.