Incident dossier · Rank #33

Google Cloud India Disruption After STT GDC Delhi Data-Center Fire

Google Cloud (impacted tenant); STT GDC / Tata Communications JV (named as the third-party facility operator only by third-party reporting; not confirmed by Google) 2026-06-05 477h 53m core impact FirePowerNetwork

On or about 5 June 2026, a fire at a third-party data-center facility in New Delhi forced an emergency power shutdown of networking equipment, isolating a non-compute Google Cloud Point of Presence (POP) in the Delhi metro and reducing available network capacity across the region. Google Cloud customers experienced elevated latency, intermittent packet loss and non-optimal routing across Delhi, Mumbai and Chennai. Google first disclosed customer impact on 9 June and worked the incident through nine status updates until resolution on 29 June, with no workaround available throughout. Recovery was gated by out-of-region capacity augmentation and, ultimately, by safety-cleared physical re-entry to the damaged site around 22-23 June. Google never named the facility, operator or ignition source; the lithium-battery/UPS attribution comes only from third-party reporting, not from Google's record.

Failure cascade

Trigger → primary fault → downstream blast radius, derived from the sourced root cause and affected-services record.

Facility & location

Operator: Google Cloud (impacted tenant); STT GDC / Tata Communications JV (named as the third-party facility operator only by third-party reporting; not confirmed by Google)
Data center: Third-party colocation facility, New Delhi (attributed by third-party reporting to the STT GDC / Tata JV site in Greater Kailash-I; the facility is never named or confirmed by Google)
Location: New Delhi, India, asia-south2 (Delhi) metro; effects across Delhi, Mumbai, Chennai
Date: 2026-06-05

Impact & scale

Users affected: Not quantified by Google; qualitative impact to Google Cloud customers whose traffic ingressed via the Delhi metro, with effects noted across Delhi, Mumbai and Chennai
Financial: Not disclosed by Google (no SLA/credit figure). Only unverified third-party tenant claims in circulation (e.g. R2 Net ~$2M; Matrix Cellular '20+ years of data' at risk)
Scope: Regional network-capacity degradation (metro POP isolation); non-compute

Services / systems down

Hybrid Connectivity
Virtual Private Cloud (VPC)
Media CDN

Impact data & metrics

Incident window (start to resolution)	2026-06-05 00:00 → 2026-06-26 12:00 US/Pacific (~21 days)
Metros with degraded Google Cloud ingress	3 (Delhi, Chennai, Mumbai)
Google Cloud services impacted	Hybrid Connectivity, Media CDN, VPC
Fire-service call time (only documented detection)	~02:45 IST, 2026-06-05
Fire tenders deployed	10
Google server racks affected	~50
Affected facility electrical capacity	1.1 MW (reported, STT Delhi 2)
Firefighter casualties	2 injured, 0 fatalities (DCD later reported 'no injuries' — discrepancy)
Independent RCA timeline	~5–7 weeks from 2026-06-23 (late-Jul to early-Aug 2026)

Magnitude profile

Magnitude 6.2 = blast 6×0.35 + users 6×0.25 + financial 5×0.20 + duration 8×0.20 (sub-scores 0–10 · weighted composite)

Duration scores high because the disclosed impact window spanned ~20 days (9-29 June) and true onset-to-resolution from ~5 June is longer. Blast radius is moderate: three metros (Delhi, Mumbai, Chennai) and three products (Hybrid Connectivity, VPC, Media CDN), but the affected POP was non-compute so no VM/data-plane loss on Google's side. Users and financial scores are constrained by the absence of any Google-disclosed quantitative metric; financial reflects unverified third-party tenant loss claims only.

Sequence of events (SOE)

2026-06-05 ~02:45 ISTTRIGGER Lithium battery units in the third-floor battery room of STT Delhi 2 fail; preliminary cause cited as a suspected short circuit, consistent with lithium-ion thermal runaway. Batteries reportedly belonged to a tenant leasing space at the site.
2026-06-05 ~02:45 ISTDETECTION Emergency call logged to the Delhi Fire Service — the only documented detection event. No in-facility VESDA/aspirating or spot smoke/heat detection system or sensed-alarm time is named in any public source (disclosed gap).
2026-06-05 ~02:45 ISTDETECTION CRITICAL SUPPRESSION GAP: no source describes the battery room's fixed suppression (clean-agent/inert-gas/pre-action), whether it discharged, or why it failed to contain a lithium-battery fire; gaseous agents would plausibly be ineffective against thermal runaway (inference).
2026-06-05 shortly after 02:45 ISTMITIGATION Delhi Fire Service personnel reportedly 'arrived within minutes' of the call.
2026-06-05 early hoursMITIGATION Ten fire tenders reportedly deployed to the site; manual firefighting operation begins and continues for several hours.
2026-06-05 during responseCASCADE Fire required an emergency power shutdown of networking equipment in the third-party facility — the pivotal protective de-energisation, not a compute-region failure.
2026-06-05 during responseCASCADE The shutdown isolated a non-compute local Point of Presence (POP) in Delhi and reduced available network capacity in the metro area.
2026-06-05 during responseIMPACT Traffic into Google Cloud from the Delhi, Chennai and Mumbai metro areas experiences slightly elevated latency and non-optimal network routing as rerouted demand exceeds regional capacity.
2026-06-05IMPACT Approximately 50 Google server racks reportedly affected; footage showed destroyed server racks, collapsed ceiling panels, scattered debris and demolished electrical infrastructure on the third floor.
2026-06-05IMPACT Equipment worth hundreds of crores of rupees reportedly destroyed; routers/servers of Netflix and multiple NCR ISPs damaged; ~20 years of Matrix Cellular data placed at risk.
2026-06-05 onwardMITIGATION Google works to restore Internet Edge peering capacity in Delhi, augment out-of-region capacity in Chennai, and optimize backbone network capacity. (A secondary account also describes 'migrating selected peering partners.')
2026-06-05 (after several hours)RECOVERY Fire brought under control and reportedly confined to the third floor; spread to other floors prevented.
2026-06-05IMPACT Two firefighters reportedly injured during the operation; no fatalities. (A later DCD report reportedly stated 'no injuries' — an unreconciled discrepancy.)
2026-06-05 onwardRECOVERY Prolonged hazard lockout: full capacity restoration is gated on obtaining fire/structural safety clearance before Google can re-energise/re-access equipment.
2026-06-15IMPACT Tata Communications, in a letter reported by Reuters, states the fire caused 'extensive damage'; clients fear decades of data lost.
~2026-06-22RECOVERY Following safety clearance, Google's team reportedly accesses the damaged site and continues restoring additional capacity through the week (specific June 22 date is reported, not in the official status text).
from 2026-06-23 (+5–7 weeks)RECOVERY STT Global reportedly commissions an independent root-cause analysis (findings due late-July to early-August 2026); Novamesh (Tata Communications) reportedly characterises the event as 'force majeure.'
2026-06-26 12:00 (US/Pacific)RESTORED Google restores all lost capacity after safety clearance; incident 'recovered and returned to normal service as of Friday, 2026-06-26 PDT.'

Root cause

SPECIFIC IGNITION SOURCE: Per third-party reporting (Data Center Dynamics; Outlook Business; NDTV Profit; People Matters), Delhi fire authorities located the origin in lithium battery units in a third-floor battery room of STT Delhi 2 (Next-Gen Tower, Greater Kailash-1, New Delhi; reported 1.1 MW; ST Telemedia / Tata Communications JV). A pivotal DCD detail is that the batteries "belonged to a company leasing space at the site" — i.e., a COLOCATION TENANT's own battery installation, not confirmed to be the operator's central UPS plant. This shifts ignition ownership from the operator's maintained infrastructure toward a tenant-controlled energy-storage deployment inside a shared hall. NOTE (QA): only Google's own Service Health page is independently re-verifiable at review time; the battery-origin, floor, facility-identity and tenant-ownership details rest on secondary outlets that could not be re-fetched and should be read as reported, not confirmed. EQUIPMENT DETAIL — DISCLOSED UNCERTAINTY: The cell chemistry is reported only as generic "lithium-ion." Make, model, manufacturer, install date, age, rated capacity (kWh/Ah), BMS design, charger/charging regime, string voltage, and battery-room thermal conditions are ALL undisclosed in every public source as of the access date. No source establishes whether the cells were LFP, NMC, or another variant — a material distinction, since NMC chemistries have lower thermal-runaway onset temperatures and higher energy release than LFP. EXACT FAILURE MECHANISM — NOT CONCLUSIVELY ESTABLISHED: A "short circuit" was cited as the suspected PRELIMINARY cause, explicitly "under investigation" (People Matters). This is consistent with lithium-ion thermal runaway seeded in a battery string, but the official cause was reported as inconclusive pending an independent root-cause analysis commissioned by STT Global (reported due ~5–7 weeks from June 23, 2026, i.e. late-July to early-August 2026). The propagation pathway, whether cell-to-cell cascade was arrested, and whether the room had thermal barriers or cell-level isolation, are unknown. LATENT ROOT — DESIGN & PROTECTION: The more consequential root causes are architectural and detection/suppression-related, and the record is notable for its SILENCE. No public source names any in-facility fire-detection system (VESDA/aspirating, spot smoke/heat) or a sensed-alarm time; the only detection datapoint is the human emergency call to the Delhi Fire Service at ~02:45 IST. No source describes the battery room's fixed suppression (clean-agent such as FM-200/Novec-1230, inert gas, or pre-action sprinkler), whether it discharged, or why it failed. Lithium-ion thermal runaway is largely unquenchable by gaseous clean agents (which displace oxygen but do not remove runaway's self-sustaining internal heat), so any installed gas system would plausibly have been ineffective — but this is analytical inference, not confirmed fact. The documented suppression record is entirely manual: Delhi Fire Service tenders over several hours. LATENT ROOT — SEGREGATION & REDUNDANCY: A single physical hall combined a tenant lithium battery installation, Google's peering/edge POP hardware, and other tenants' equipment (reported: Matrix Cellular, Netflix, NCR ISPs) with insufficient compartmentation; damage was confined to the third floor, but that floor concentrated enough shared infrastructure to force a metro-wide capacity cut. On the Google side, the latent root of the CLOUD disruption was topological and IS officially confirmed: the emergency de-energisation "isolat[ed] a non-compute local Point of Presence (POP) in Delhi," degrading ingress across THREE metros — a redundancy/blast-radius design gap in edge placement, NOT a compute-region (asia-south2) failure (Google Cloud Service Health, incident 5fGQt4VbkDnr3Yp8PXPr). LATENT ROOT — REGULATORY VACUUM: MediaNama (unverifiable at review) attributes the deeper cause to India's regulatory environment: the DPDP Draft Rules mandate data localisation but set no facility fire-safety standard, redundancy requirement, or minimum-uptime obligation; data centres are treated as ordinary buildings — a systemic latent condition amplifying a single-facility fire into a national-scale digital event. MAINTENANCE LAPSE — STATUS: No specific maintenance, inspection, BMS-calibration, charging-control, or fire-barrier-testing lapse is evidenced in any public source. That venue is the pending STT RCA, whose findings are not public. Novamesh's "force majeure" characterisation is a contractual disclaimer, not an investigative conclusion. Any maintenance root cause is therefore UNKNOWN pending the RCA — a gap this dossier flags rather than fills.

Contributing factors

Colocation tenant-owned lithium battery installation in a shared third-floor battery room: DCD reported the igniting batteries 'belonged to a company leasing space at the site,' meaning the failed energy-storage system was under tenant control inside a hall shared with Google, Netflix and ISP equipment — a segregation/compartmentation gap (Data Center Dynamics, unverified at review).
Absent or undocumented in-facility fire detection: no public source names any VESDA/aspirating or spot smoke/heat detection or a sensed-alarm time; the only detection event is the human ~02:45 IST call to the Delhi Fire Service, implying either no effective early automated detection or undisclosed detection (People Matters; forensic record).
No evidenced fixed fire-suppression activation: the record contains no description of a clean-agent, inert-gas, or pre-action system discharging or failing in the battery room; documented suppression was entirely manual DFS firefighting — leaving open whether a system was absent, ineffective against lithium runaway, or undisclosed (forensic record; Outlook, unverified).
Single-POP edge topology with cross-metro blast radius [OFFICIALLY CONFIRMED]: the emergency shutdown isolated one 'non-compute local POP' in Delhi, and rerouting degraded Google Cloud ingress across the Delhi, Chennai and Mumbai metro areas — a network-redundancy gap distinct from any compute-region failure (Google Cloud Service Health 5fGQt4VbkDnr3Yp8PXPr).
Regulatory vacuum on data-centre safety/redundancy: India's DPDP Draft Rules reportedly mandate localisation but set no facility fire-safety standard, redundancy requirement, or minimum-uptime obligation, and data centres are regulated as general buildings — a latent condition amplifying a single-site fire (MediaNama, unverified at review).
Prolonged post-fire hazard lockout extended restoration [OFFICIALLY CONFIRMED gating]: Google could restore all lost capacity only after obtaining safety clearance, with resolution on 2026-06-26 — the restoration bottleneck was structural/fire safety, not network engineering (Google Cloud Service Health).
Unknown battery-room maintenance/BMS/charging regime: no source evidences the inspection, thermal-monitoring, BMS-calibration, or charging-control status of the failed batteries; this remains pending the STT-commissioned independent RCA (Outlook, unverified; forensic record).

Correction of errors (COE)

Complete and publish the independent root-cause analysis of the ignition source, battery chemistry/BMS, and detection/suppression performance STT Global / STT GDC India · Reported commissioned ~2026-06-23; findings due late-Jul–early-Aug 2026; not public at review
Restore and diversify Delhi Internet Edge peering / augment out-of-region (Chennai) capacity to remove single-POP cross-metro blast radius Google Cloud · Officially confirmed restored/augmented; incident resolved 2026-06-26 (durable topology fix not confirmed)
Review battery-room compartmentation and segregate tenant-owned energy storage from shared IT/peering halls STT GDC (facility operator) · Unknown — pending RCA
Review battery-room fire detection (VESDA/off-gas) and lithium-appropriate suppression adequacy STT GDC (facility operator) · Unknown — pending RCA
Establish colo safety SLA governing tenant-owned battery maintenance, BMS telemetry and inspection cadence STT GDC / colocation tenants · Not evidenced
Advocate/adopt data-centre-specific fire-safety, redundancy and minimum-uptime standards under DPDP framework MeitY / regulator · Not started — regulatory gap per reporting

Lessons learnt

A physical fire in a colocation tenant's battery room can cascade into a hyperscaler edge outage via a deliberate protective de-energisation — the damage vector was a safety shutdown, not fire reaching cloud compute.
Edge blast-radius matters as much as compute redundancy: one non-compute Delhi POP carried enough peering/ingress capacity that its loss degraded three metros (Delhi, Chennai, Mumbai) — a topological single point of failure invisible in region-level SLAs.
Recovery from a physical hazard is gated by safety clearance, not engineering: the ~21-day tail to 2026-06-26 was driven by structural/fire lockout, so DR planning must model multi-week physical-access denial, not just failover time.
Lithium-ion suppression is a distinct discipline: gaseous clean agents displace oxygen but cannot remove thermal-runaway self-heating, so a 'compliant' gas system can be effectively useless against a battery-origin fire.
Shared-hall compartmentation and tenant-equipment governance are systemic risk controls: co-locating tenant energy storage with hyperscaler peering and other tenants' gear concentrates unrelated parties' fate into one floor.
Localisation mandates without safety/redundancy standards concentrate national risk: policy that forces data in-country but sets no facility resilience floor turns a single-site fire into a national digital event.
Disclosure discipline is itself a finding: the total silence on detection systems, suppression discharge, and battery specifications is a governance gap — what is not measured or reported cannot be assured.

Improvements & remediation

SAFETY — Battery-room compartmentation and lithium-appropriate suppression: enforce cell/module-level thermal-runaway isolation, fire-rated barriers between energy-storage and IT/peering equipment, and suppression rated for lithium fires (water-based deluge/mist or immersion) rather than gas-only clean agents, which cannot arrest runaway self-heating.
SAFETY/DETECTION — Mandatory early multi-modal detection: aspirating (VESDA) smoke plus lithium off-gas sensing (H2/CO/electrolyte vapour) and heat, with logged sensed-alarm timestamps, so ignition is detected before open flame instead of relying on a human 02:45 call.
MAINTENANCE — Governed battery-health program for ALL batteries in shared halls, including tenant-owned: contractual colo safety SLA requiring BMS telemetry, periodic thermal-imaging of strings, charging-regime/charger audits, install-date/age tracking, and documented inspection cadence — closing the currently-undisclosed maintenance record.
MAINTENANCE/TESTING — Periodic fire-system commissioning and drills: scheduled discharge/functional testing of the fixed suppression, detection-to-suppression interlock verification, and battery-room evacuation/isolation drills, with results retained and auditable.
NETWORK REDUNDANCY — Eliminate single-POP cross-metro blast radius: distribute Delhi peering/edge capacity across physically diverse POPs so no single non-compute POP loss can degrade ingress across three metros; pre-provision out-of-region failover peering for Delhi/Chennai/Mumbai.
GOVERNANCE — Tenant energy-storage segregation policy: prohibit tenant-owned lithium storage inside shared IT halls without dedicated fire-rated rooms, standalone detection/suppression, and operator oversight of the installation and its maintenance.
REGULATORY — Adopt data-centre-specific standards: fire-safety, redundancy (N+1/2N), and minimum-uptime obligations for facilities hosting localised/critical data, closing the DPDP-rules gap that treats data centres as ordinary buildings.

Comprehensive analysis

A cross-domain cascade, not a cloud failure

The defining feature of this incident is that the Google Cloud disruption was never a cloud failure in the conventional sense. Google's own Service Health record is explicit: a fire at a third-party facility 'required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi.' Cloud compute (the asia-south2 region) was not destroyed; a deliberate, safety-driven de-energisation of Google's peering/edge gear inside someone else's building was the damage vector. Root-cause analysis that stops at 'India outage' misses that the failure crossed three domains — a tenant's battery, a colocation operator's hall, and a hyperscaler's edge topology — linked by one protective action.

The confirmed spine vs. the reported flesh

At review, only Google's vendor-status page is independently re-verifiable; it confirms the non-compute POP isolation, the three affected metros (Delhi, Chennai, Mumbai), the impacted services (Hybrid Connectivity, Media CDN, VPC), the safety-clearance-gated recovery, and resolution on 2026-06-26. Everything upstream of the shutdown — battery origin, third-floor room, tenant ownership, short-circuit cause, facility identity/1.1 MW, rack counts, casualties, RCA and force-majeure framing — rests on secondary Indian outlets (DCD, People Matters, Outlook, The Hindu, Reuters, MediaNama) that could not be re-fetched due to network restrictions and an exhausted search budget. Those claims are internally consistent and plausibly real, but this dossier marks them 'reported/unverified' rather than confirmed.

The detection and suppression silence

The most damning aspect of the physical record is what is absent. No source names any in-facility detection system or a sensed-alarm time — the only detection datapoint is a human 02:45 IST call to the fire service. No source describes any fixed suppression in the battery room, whether it discharged, or why it failed. This silence is analytically loaded: lithium-ion thermal runaway is largely unquenchable by gaseous clean agents, so even a 'compliant' gas system would plausibly have been ineffective. That is inference, not fact — but the inference is precisely why the missing disclosure matters, and why the pending RCA should be judged on whether it addresses detection and suppression, not just ignition.

Edge topology as the true amplifier

On the network side, the officially confirmed root is topological: a single non-compute POP carried enough Delhi peering/ingress capacity that its loss, plus rerouting, degraded ingress across three metros with 'no available workaround' for affected traffic. This is a blast-radius/redundancy gap that region-level availability SLAs do not surface. The recovery profile reinforces the lesson — restoration was gated on physical safety clearance, producing a ~21-day tail unrelated to network engineering. Resilience planning that models failover time but not multi-week denial of physical access to a burned facility would have badly underestimated this event.

Systemic and regulatory latent conditions

Two latent conditions turned a local fire into a national event. First, colocation shared-hall design placed a tenant's energy storage alongside a hyperscaler's peering and other tenants' equipment with insufficient compartmentation, concentrating unrelated parties' fate on one floor. Second, per MediaNama's (unverified) reading, India's DPDP draft rules mandate data localisation without any facility fire-safety, redundancy, or uptime floor — so critical data is forced in-country into buildings regulated as ordinary structures. The corrective agenda therefore spans three owners: the operator (compartmentation, detection/suppression), the hyperscaler (edge diversity), and the regulator (data-centre-specific standards).

Evidence quality and disclosed gaps

This review upgraded source attribution where the official page now confirms facts (POP isolation, three metros, services, 2026-06-26 resolution, safety-clearance gating) and rescoped two items the official text refines: the mitigation wording ('migrating selected peering partners' is secondary, not official) and the '~June 22 re-access' date (reported, not in the status text). No claim was fabricated to fill a gap; disclosed uncertainties — battery chemistry, BMS/charging regime, detection/suppression presence, exact failure mechanism, and any maintenance lapse — remain flagged as unknown pending the STT RCA. The honest posture is a confirmed cascade spine wrapped in well-labelled, still-unverified forensic reporting.

Technical deep-dive

This was a cross-domain cascade in which a physical fire in a colocation tenant's battery room propagated into a hyperscaler's network-edge outage through a deliberate protective action, not through direct fire damage to cloud compute. The chain has three layers; only Layer 2 and its outcome are independently confirmed by Google's own Service Health record, while Layer 1's fire-forensics rest on secondary reporting that could not be re-fetched at review time. LAYER 1 — THE PHYSICAL FIRE. At ~02:45 IST on 2026-06-05, lithium battery units in the third-floor battery room of STT Delhi 2 entered what fire authorities preliminarily attributed to a short circuit — the classic seed of lithium-ion thermal runaway (People Matters; DCD, unverified at review). DCD reported the batteries "belonged to a company leasing space" — a tenant, not confirmed to be the operator's UPS plant. The only detection event in the public record is the human call to the Delhi Fire Service at ~02:45 IST; whether any in-facility aspirating/spot detection alarmed earlier is undisclosed. No fixed suppression discharge is documented — a critical gap, because a battery-origin lithium fire would likely defeat gaseous clean-agent systems, which cannot remove runaway's internal self-heating. Suppression was therefore reported as entirely manual: DFS arrived "within minutes," deployed ten tenders, and fought the fire for several hours, confining it to the third floor. Reporting described destroyed server racks, collapsed ceiling panels and demolished electrical infrastructure (NDTV Profit). Two firefighters were reported injured with no fatalities (Outlook; People Matters; The Hindu) — though a later DCD report reportedly stated "no injuries," an unreconciled discrepancy this dossier flags rather than resolves. LAYER 2 — THE PROTECTIVE DE-ENERGISATION (THE CASCADE TRIGGER) [OFFICIALLY CONFIRMED]. Per Google Cloud Service Health (incident 5fGQt4VbkDnr3Yp8PXPr): "A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi." This is the hinge of the whole event: the cloud impact was caused by a deliberate, safety-driven shutdown of Google's own peering/edge gear co-located in the third-party hall — NOT by fire destroying a compute region (asia-south2 is merely the Delhi region label). "Non-compute" means peering/edge/ingress rather than customer VMs. LAYER 3 — THE METRO-SCALE PROPAGATION [OFFICIALLY CONFIRMED]. Removing that POP's capacity forced rerouting, producing "slightly elevated latency and non-optimal network routing" for traffic into Google Cloud from the Delhi, Chennai and Mumbai metro areas as demand exceeded regional capacity. One POP loss thus degraded three metros — an edge blast-radius/redundancy characteristic. Google's documented mitigations (per the status page) were: restoring Internet Edge peering capacity in Delhi, augmenting out-of-region capacity in Chennai, optimizing backbone capacity, and restoring the Delhi-Chennai and Delhi-Mumbai connections. (A secondary account (Data Center Knowledge) additionally framed the response as "migrating selected peering partners"; that phrasing is not in the official text.) Full restoration was gated on physical safety: Google could only restore all lost capacity after obtaining safety clearance, with the incident "recovered and returned to normal service as of Friday, 2026-06-26 PDT" — a ~3-week tail driven by fire/structural hazard lockout, not network engineering. Beyond Google, the same hall reportedly damaged Netflix and NCR-ISP equipment and threatened ~20 years of Matrix Cellular data, with losses in the "hundreds of crores" of rupees (The Hindu; Outlook, unverified at review). STT Global reportedly commissioned an independent RCA (due ~5–7 weeks from June 23); Novamesh (Tata Communications) reportedly framed it as force majeure.

References & provenance

vendor-status Google Cloud Service Health incident 5fGQt4VbkDnr3Yp8PXPr (22 June site access)“teams obtained access to the damaged site and will further restore additional incremental user-facing backbone capacity on Tuesday, 2026-06-23”https://status.cloud.google.com/incidents/5fGQt4VbkDnr3Yp8PXPr
vendor-status Google Cloud Service Health incident 5fGQt4VbkDnr3Yp8PXPr (12 June remediation ETAs)“we are further augmenting our Delhi backbone capacity (expected to be complete by Monday, 2026-06-15 PDT) ... augmenting out-of-region Internet Edge regional peering capacity in Chennai ... (expected to be done by Wednesday, 2026-06-17 PDT)”https://status.cloud.google.com/incidents/5fGQt4VbkDnr3Yp8PXPr
official-status Google Cloud Service Health incident 5fGQt4VbkDnr3Yp8PXPr (primary status record)“A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area.”https://status.cloud.google.com/incidents/5fGQt4VbkDnr3Yp8PXPr
official-status Google Cloud Service Health incident 5fGQt4VbkDnr3Yp8PXPr (affected services)“Affected Services: Hybrid Connectivity, Virtual Private Cloud (VPC), Media CDN”https://status.cloud.google.com/incidents/5fGQt4VbkDnr3Yp8PXPr
news Fire at STT GDC/Tata data center in India caused 'extensive damage' (report)“Third-party reporting attributes the fire and extensive damage to the STT GDC (ST Telemedia-Tata JV) Delhi facility; Google's own record names neither the facility nor the ignition source.”https://www.datacenterdynamics.com/en/news/fire-at-stt-gdctata-data-center-in-india-caused-extensive-damage-report/
news Tata Delhi data centre fire sparks data loss fears; Google Cloud disrupted“Press reporting describes tenant data-loss fears (e.g. Matrix Cellular's multi-decade records, R2 Net's ~$2M) that remain unverified against the operator's 'majority recovered / not material' position.”https://www.business-standard.com/technology/tech-news/tata-delhi-data-centre-fire-sparks-data-loss-fears-google-cloud-disrupted-126062401328_1.html

Sourced from public post-incident reports. Quotes are short attributed excerpts for provenance only; the analysis above is original and substantially shorter than its sources. Last verified 2026-07-31.