Summary
- A fire at a third-party data centre required an emergency shutdown of networking equipment in Delhi.
- Google Cloud traffic from Delhi, Chennai, Mumbai, and surrounding areas experienced elevated latency and possible packet loss.
- The incident shows how physical facility failures can affect cloud service performance through network routing and local capacity constraints.
Google Cloud customers in parts of India experienced intermittent network disruption after a fire at a third-party data centre facility in Delhi required an emergency shutdown of networking equipment.
The incident isolated a non-compute local point of presence in Delhi and reduced available network capacity in the metropolitan area. Google’s service health update said network traffic to Google Cloud originating from Delhi, Chennai, Mumbai, and surrounding areas experienced intermittent periods of elevated latency and possible packet loss.
The incident began on 9 June 2026 at 11:22 US Pacific time. Google said affected customers could experience elevated latency and non-optimal routing into Google Cloud until the facility was fully restored, while traffic mitigations and additional peering capacity were being pursued.
Google did not identify the third-party facility, disclose the cause of the fire, or provide detail on damage. The issue was not framed as a compute region outage, but as a network-capacity and routing problem caused by a physical facility incident.
Cloud resilience still depends on buildings
Cloud services are often described through abstract service levels, but the operating model still relies on physical facilities, power systems, local points of presence, carrier routes, peering capacity, and third-party sites. A disruption in one building can shift traffic onto less optimal paths and reduce local serving capacity across a metro area.
A non-compute point of presence can still be operationally important. If a facility hosts networking equipment, edge connectivity, or peering infrastructure, an emergency power shutdown can create latency, packet loss, routing inefficiency, and degraded user experience, even if the main compute region remains available.
The incident also highlights third-party dependency. Cloud providers engineer redundancy across regions and networks, but external facilities introduce questions around fire detection, suppression, electrical isolation, incident escalation, restoration priority, and customer communication. A cloud customer may buy an availability commitment from a platform provider, yet the platform remains exposed to buildings, power rooms, cables, and local infrastructure controlled by other parties.
Carrier hotels, colocation facilities, and network points of presence are essential parts of resilient digital infrastructure. Their value depends on diversity and operational discipline: multiple routes, clear dependency mapping, tested incident procedures, and enough capacity headroom to absorb sudden loss of a site.
The case also lands in a period when data centres are being treated more explicitly as critical infrastructure. Facility resilience, network resilience, and customer continuity are increasingly difficult to separate. A fire can become a cloud performance event; a power shutdown can become a routing problem; and a local network constraint can affect customers far from the original facility.
Google’s service health page gives useful technical detail on the location, symptoms, timing, mitigation work, and absence of a workaround. A fuller post-incident review would help clarify restoration time, routing impact, third-party dependencies, and whether additional local capacity or peering diversity will be added in the Delhi metro.
