Delhi Data Center Fire Blast Radius Audit for Your Stack

The Delhi data center fire began on 5 June 2026 at a facility operated by STT Global Data Centres and leased by Tata Communications. Most local outages end within hours. This one did not, and the physical damage turned it into a case study in blast-radius planning for any team that relies on cloud services.

In this essay we set out what the public reports say happened, the failure classes it shows, four audit questions for your own stack and a tabletop exercise. We also say where the lesson stops applying.

What Happened in the Delhi Data Center Fire

According to Silicon UK, Delhi fire authorities identified lithium battery units as the source of the fire at the STT GDC India facility. Tata Communications said the fire "caused extensive damage" and that the damage made recovery of the affected data and systems difficult.

Date (2026)	Reported event
5 June	Fire at the facility, traced to lithium battery units
9 June	Google cites a fire at a third-party data centre and shuts down some networking equipment
23 June	Google warns of continuing latency in India with no workaround
24 June	An Indian SIM provider says it may have lost over 20 years of data
26 to 30 June	Google reports restoration, and Tata says most affected customer data was recovered

The Outlook Business report quotes Matrix Cellular's chief executive saying, "It's been 20 days and they have not restored backup." It also says STT GDC commissioned an independent technical analysis expected to take five to seven weeks, and that an internet provider, R2 Net, estimated a $2 million loss.

A later report in W.Media says Tata Communications recovered a majority of affected customer data, with only limited cases needing validation and rebuilding. We include that outcome because it matters. The fear of total loss was real for weeks, and the final damage was smaller than the early reports suggested.

Three Failure Classes in One Physical Event

The fire was not a software bug or a configuration error. It was a lower-level failure that bypassed redundancy built higher up the stack. We see three distinct classes in it.

1. Shared Fate Between Data and Backup

A customer fearing the loss of two decades of records suggests that copies were not independent of the building. We cannot say how any individual customer was set up. The pattern still deserves checking in your own estate.

2. Partial Degradation From a Lost Interconnect

Google is strong at redundancy, and its customers in India still saw intermittent network disruption linked to the fire. A lost interconnect node means traffic must reroute, with extra latency and packet loss until capacity returns.

3. Dependencies Customers Did Not Know About

Many affected teams were customers of a cloud provider or an ISP, not of the building. They learned of the dependency when their services slowed, and then waited for someone else's explanation.

Key Takeaway. A physical facility failure creates shared-fate risk that can degrade even sophisticated cloud architectures for weeks.

Four Audit Questions for Your Own Blast Radius

We would put these four questions to the team that owns infrastructure, and answer them with evidence and not memory.

1. Check If Any Backup Shares a Building With Its Primary

Verify the physical location of primary storage and of each backup. Two copies in one building share a power connection, a fire suppression system and often a battery room. Move critical backups to a different region or at least to a different facility, and test a restore from them.

2. Map the Single Facilities Your Traffic Silently Uses

Many teams audit compute and database locations and ignore the network edge. Map where traffic from each region enters your network, including points of presence, DNS and peering. If one site carries a whole region, you are one incident from a regional blackout.

3. Compare Your Own Telemetry With the Status Page

Provider status pages summarise across customers and can lag behind a specific customer's experience. Compare your own service level indicators with the provider's page during the next minor event. Run synthetic probes that simulate user journeys from specific regions, so you detect degradation before it is acknowledged.

4. Find Out Whose Root Cause Analysis You Are Waiting On

In Delhi, an independent technical analysis was expected to take five to seven weeks. If your business waits for a vendor's document to learn where the failure sits, your incident process has a dependency bug. Gathering evidence from logs, network and configuration is the work where we would use dedicated AI agents that bring the relevant evidence together, while engineers decide on failover.

Our guide to a triage protocol for third-party outages gives a fifteen-minute order of checks for the moment a provider incident starts, and our analysis of a correlated model provider outage shows the same hidden dependency in another layer.

When Protecting Against Everything Becomes the Risk

A common reaction to a data center fire is to demand active-active multi-cloud for everything. We think that is usually the wrong lesson. The extra complexity can cause more incidents than it prevents, as our piece on cascading failure and normal accidents argues.

The goal is not to survive any event. The goal is to avoid sharing fate. You do not need a second cloud in another country to survive a fire in Delhi. You need to be sure that your data and your connectivity do not hang on one building.

A One-Hour Tabletop Exercise for Your Next Ops Review

To turn the audit into practice, we would run this exercise with the infrastructure team.

1. Set the scenario. It is Friday afternoon, a fire has broken out in the battery room of your primary facility, or of your provider's primary site for your stack, and the site is offline for at least two weeks.
2. Ask what is gone for good. Check where your backups physically live.
3. Ask how you tell your users. Check your status page triggers and who can publish.
4. Ask how you route around it. Check DNS, points of presence and failover runbooks.

We find the exercise valuable mostly for the arguments it starts. Most teams discover at least one answer that begins with an assumption.

Common Pitfalls in Blast-Radius Planning

There are four common mistakes in blast-radius planning, and we would give each a simple check.

• Trusting zones blindly. Check what an availability zone shares, such as a utility connection, before treating it as independent.
• Ignoring the point of presence. Multi-region compute does not help if all traffic enters through one site.
• Unverified backups. A backup you have never restored is a hope and not a copy.
• Waiting for the vendor. Build the telemetry to find where a failure sits without a provider's report.

Run the Blast-Radius Audit Before the Next Fire

The Delhi data center fire is a reminder that infrastructure is physical, and that abstraction hides the building until it fails. Answer the four audit questions, run the tabletop exercise and test one restore this month.

We would begin with question one, since it is the cheapest to answer. When you want agents to gather the evidence during a provider incident, Operate runs dedicated AI agents that investigate production problems with cited evidence and propose fixes for your team to review.