ITOM for Data Centers: What Fails When the Chiller Does
On November 28, 2025, a cooling failure at a data center in Aurora, Illinois, disrupted CME Group’s markets for more than 10 hours. Temperatures rose above 100°F, and trading in products including gold, oil, and interest rates stopped across global markets.
CME did not switch to its backup facility. Bloomberg reporting republished by Insurance Journal cited a person familiar with the decision who said available information pointed to a brief outage.
The incident illustrates a difficult operational decision. When cooling fails, teams must identify affected equipment, services, and customers while assessing whether recovery options are viable. ITOM for data centers gives operations teams a way to prepare the infrastructure and service records needed for those decisions.
What is ITOM for data centers, and what does it cover?
IT operations management, or ITOM, covers the processes and tools used to operate and maintain IT infrastructure and services. IT operations management for data centers specifically includes discovery, dependency mapping, event handling, and coordination across incident and change workflows — the pieces that have to work together when a cooling or power fault hits the floor.
The infrastructure team may know which switches, servers, and storage systems support a service. The facilities team may separately maintain cooling loops, power feeds, and rack locations. A usable response plan brings those records together so each team can assess the same affected area.
Data center infrastructure management, or DCIM, addresses the physical facility. DCIM tools can track conditions such as power, cooling, and space. Monitoring tools raise alerts when equipment or thresholds require attention. ITOM adds the operational processes and IT dependency records that help teams assess service impact. For a closer look at the hardware side of that same environment, see Virima’s guide to ITAM for data centers.
What the alarm knows versus what it does not
A cooling alert can identify the affected equipment or zone. Responders still need to establish which racks sit in that zone and which services depend on those racks.
The same problem appears in other parts of the facility:
- A UPS alert identifies a power problem, while responders check the feed records for exposed racks.
- A switch failover changes the network path, while engineers investigate which storage connections use that path.
- A recovery decision requires an inventory of services, dependencies, and available capacity at the alternate site.
This requires records that teams have actively reviewed and maintained. Discovery can help refresh supported IT relationships, while facilities and service owners validate information outside its scope.
Why thermal, power, and network faults spread
The immediate fault may affect one component, but shared dependencies can widen its impact. A power feed can support multiple racks. A network path can connect several storage systems. An application can rely on an infrastructure service operated by another team.
The Uptime Institute’s 2026 outage analysis announcement identifies power as the leading cause of impactful outages. It also reports that fiber and connectivity outages are increasing and are more likely to cause extended disruptions.
Software dependencies can produce similar cascades. In October 2025, a DNS issue affected Amazon DynamoDB in the Northern Virginia region. AWS’s post-event summary describes subsequent effects on new EC2 instance launches and Network Load Balancer connections, the same shared-dependency pattern that shows up in ITOM for oil and gas production environments.
Those incidents do not establish that a particular map would have prevented either outage. They show why operators need to understand connections beyond the component that first raises an alarm.
Four places the dependency chain goes dark
Shared dependencies break down in predictable places:
| Where it breaks | Why it goes dark |
|---|---|
| Facility records stop at the rack | Cooling zones and power feeds aren’t linked to service inventories, so engineers assemble that link mid-incident instead of before it |
| Network diagrams lag device changes | A diagram goes stale once switch ports, storage paths, or failover arrangements change, so engineers must verify the active path before isolating a component |
| Maintenance plans omit an impaired partner | A planned intervention can remove redundancy while another path is already degraded — the change owner needs both facts to catch that |
| Recovery plans name sites without service dependencies | Service requirements stay scattered across teams, leaving responders to check capacity, connectivity, and readiness during cutover instead of before it |
What an unmapped facility costs each team
Operations leaders running ITOM for data centers need to make decisions when the duration and reach of an incident are uncertain. An incomplete dependency record adds another task: establishing which services and customers might be affected before teams can prioritize their response.
Financial consequences vary by incident. In Uptime Institute’s 2025 annual outage analysis, 57% of respondents said their most recent major outage cost more than $100,000. One in five reported costs above $1 million. These figures describe surveyed respondents’ reported outages and should not be treated as a prediction for a particular facility.
For network operations center and infrastructure managers, the immediate cost can be investigative work. Engineers may need to locate a device owner, compare diagrams, and confirm whether a storage or network path remains available. That same investigative gap is what shows up when the service desk and the CMDB disagree about a configuration item during an incident.
For providers, the scope can extend across customer boundaries. The same report found that third-party IT and data center providers accounted for about two-thirds of publicly reported outages in its nine-year tracking period. That figure covers publicly reported incidents and does not represent the share of all outages.
How a discovery-fed dependency map supports data center outage response
A dependency map helps teams start with documented relationships during a change or incident. Its usefulness depends on discovery coverage, supplied service definitions, and review by the people who maintain the underlying records.
1. Refresh supported infrastructure records
Scheduled discovery gathers information about reachable IT assets and their supported relationships. For a data center team, a scoped discovery cycle can help identify switches, servers, and storage systems within the selected environment.
The discovery schedule should reflect each environment’s pace of change, and teams should review failed scans and inaccessible devices as part of it. A map cannot represent a relationship that discovery did not observe or that has not been supplied through another validated source — facilities records need their own review process, since cooling loops, rack locations, and power feeds stay with the owners responsible for them unless their representation has been confirmed.
2. Connect infrastructure to defined services
Service owners provide the definitions of the applications and websites that make up each service. Virima then builds ViVID™ dependency maps — a form of service dependency mapping — from those definitions and available infrastructure data.
This kind of data center dependency mapping helps an engineer trace supported relationships from an affected switch, server, or storage component toward the services that rely on it, and gives change reviewers a shared starting point for discussing potential impact.
Teams should validate critical paths with service owners. A discovered relationship is valuable evidence, and human review helps establish whether the recorded service scope matches operational expectations.
3. Use a shared record during changes and incidents
Change and incident teams can consult the same configuration item and service records when assessing impact. A change owner can review affected dependencies before a maintenance window. An incident responder can use those records to identify teams that may need to investigate.
Monitoring and DCIM tools continue to detect conditions in the facility. Engineers interpret those alerts alongside the dependency record and the current incident details.
| Operational task | Records maintained separately | Discovery-fed dependency records |
|---|---|---|
| Detect a fault | Monitoring and DCIM tools raise alerts. | Monitoring and DCIM tools raise alerts. |
| Assess service impact | Responders reconcile diagrams, inventories, and owner knowledge. | Responders consult available infrastructure and service relationships. |
| Plan a change | Engineers gather dependency information for each review. | Engineers review recorded paths and validate gaps. |
| Consider failover | Teams assemble service and recovery information during the decision. | Teams start with maintained records and verify capacity and readiness. |
| Review the incident | Teams reconstruct which records were available. | Teams compare documented relationships with findings from the response. |
Where the map changes the decision
The following examples show how operations teams can use dependency records alongside facilities information. Each scenario assumes that the relevant relationships have been documented and checked.
Chiller maintenance window. Facilities identify the affected rows in their records; infrastructure owners confirm which critical equipment and services occupy them before approving the work.
UPS replacement. Engineers compare the affected racks against service dependencies and confirm the alternate feed’s condition before cutover.
Core switch upgrade. The network team verifies the alternate path and agrees on a rollback procedure with the service owners.
Failover call. Recovery teams check capacity, connectivity, data readiness, and ownership before authorizing a cutover.
Post-incident review. Responders record which relationships were missing or inaccurate, and the responsible teams update their records and set the next validation date.
Virima shows what depends on each switch, server, and storage path
Virima combines scheduled IT discovery, configuration records, and ViVID™ service mapping to support ITOM for data centers. Together, these give infrastructure teams a view of supported relationships between IT components and the services their teams define.
The useful starting point is narrow: the network and storage devices serving one hall, treated as something to investigate rather than a ready-made authority. An outdated owner or an unconfirmed relationship is a normal first-pass finding, not a failure of the tool.
What keeps that view accurate afterward is ownership, not software: a discovery schedule, a service definition owner who revisits it when something changes, and facilities staying responsible for the environmental data only they maintain. Virima’s records sit alongside existing incident and change processes rather than replacing them.
Explore Trusted Runtime Truth for a closer look at how discovery-sourced records support decisions about what exists, how components connect, what changed, and what may be affected.
From reacting to alarms to operating from a map
Responders need two things before an incident: a maintained infrastructure record, and clear ownership of which relationships get reviewed and when.
Faster scoping, applied consistently
When an alert identifies a location or component, responders compare it with available IT records. A documented service owner gives the incident lead someone to contact for impact validation — a step that directly helps cut MTTR (mean time to resolution) during a live incident. A dependency record identifies a path to investigate; current monitoring and service checks confirm the condition during the event.
Making that repeatable means treating gaps the same way every time: if an important relationship cannot be verified before a maintenance window, the change team should treat it as a blocker rather than approve around it, and a failover call needs the service list ready beforehand, not assembled mid-outage.
Getting started
- Choose one hall or operational scope. List the shared cooling, power, and network components that teams need to understand.
- Run discovery on supported IT devices. Include the relevant network, server, and storage scope, then investigate failed scans.
- Define the services. Ask service owners to supply the applications and websites that make up each service.
- Validate important relationships. Compare discovered IT records with facilities documentation and assign people to resolve gaps.
- Set a review cadence. Document discovery schedules, service ownership, change reviews, and the process for updating facility records.
Build a clearer picture before the next incident
A cooling or power alert can start a decision that crosses facilities, infrastructure, and service teams. Preparing those teams means documenting the connections they need and checking who owns each record.
Start with one operational scope and compare its IT dependencies with the facility information your teams already maintain. Request a demo to discuss how scheduled discovery and service mapping can support that review.
Frequently Asked Questions
What is ITOM for data centers?
ITOM for data centers covers the processes and tools used to operate IT infrastructure and services. It includes discovery, dependency mapping, event handling, and coordination between teams responsible for incidents and changes.
How can ITOM help prevent data center outages?
ITOM supports prevention by giving change teams infrastructure and service information to review before maintenance. Monitoring, facilities maintenance, tested recovery plans, and human decisions remain necessary to address equipment faults and operational risks.
What is the difference between ITOM and DCIM?
DCIM focuses on physical facility resources such as power, cooling, equipment, and space. ITOM covers the operation of IT infrastructure and services. Teams can use information from both disciplines to assess potential service impact.
How does Virima support data center incident response?
Virima provides scheduled IT discovery, configuration records, and ViVID™ service maps. Responders can use supported infrastructure relationships and service definitions to investigate potential impact alongside their monitoring and facility records.
Does Virima define business services automatically?
Service definitions are supplied by the organization, including the applications and websites that make up each service. Virima then builds ViVID™ dependency maps using those definitions and available infrastructure information.
