A fire at a facility Google does not own took out a Delhi routing hub, exposing how thin hyperscaler redundancy can get when the chokepoint is a third party data center.
A fire at a facility Google does not own took out a regional routing hub for Google Cloud in Delhi on June 9, and a week later, traffic from Delhi, Chennai, Mumbai, and surrounding metros is still degraded. Google's public answer, more capacity, is the right diagnosis. The cadence of public updates, however, has been thinner than a week of multi-metro latency warrants, and the underlying structural fact is harder than the outage itself: hyperscaler redundancy in India runs through third-party colocation facilities, and one of them caught fire.
The incident began on June 9, 2026, when a fire at a third-party data center in Delhi forced an emergency power shutdown of networking equipment on the Google side of the building, according to reporting by Simon Sharwood at The Register, citing Google's own Cloud status page. The shutdown isolated a non-compute local Point of Presence, a regional routing hub that aggregates traffic into Google's backbone rather than running customer workloads, in Delhi, reducing the network capacity available to Google Cloud customers across the metro.
Because that aggregation point also sits on the path for traffic originating in Chennai and Mumbai, the impact did not stop at Delhi. Google's status page warned customers they may see "intermittent periods of elevated latency and possible packet loss" for traffic into Google Cloud from Delhi, Chennai, Mumbai, and surrounding areas, and that service may run with "slightly elevated latency and non-optimal network routing into Google Cloud" until the facility is fully restored, as quoted on the Google Cloud Status Dashboard.
Google says it has applied "traffic mitigations" that "improved performance for some Cloud customers" and that it is arranging extra peering capacity. The qualifier matters. "For some" is the company's own framing, and it is the framing that tells a customer in Chennai or Mumbai reading the public dashboard whether their specific path is one of the lucky ones. There is no public list of which customers, workloads, or regions fall on which side of "some," and there is no public Service Level Agreement credit table for this incident.
The forward-looking commitments are also the company's own. As of the June 14 article in The Register, Google said it hopes to have "better news on Monday," which works out to June 15, 2026, on the regional Delhi backbone, and is targeting Wednesday, June 17, 2026, for completion of additional peering capacity in Chennai intended to help large Indian ISPs reach Google. Both are forward commitments, not completed work, and both were made by Google on its own status page rather than by The Register.
The structural lesson is the part the wire does not usually get to. Hyperscalers describe regional cloud footprints in terms of zones and regions, but in practice the physical footprint inside a country is a set of colocation leases. Google does not run its own data centers in India in the way it does in some other markets, and the routing hub that burned last week was inside a facility owned by a third party whose name has not been disclosed. That ownership gap is not a footnote. It is the reason a single building fire can degrade Google Cloud traffic for a week across four metros in a country of 1.4 billion people, and it is the reason the customer-facing language stays cautious: when the chokepoint is someone else's facility, the cloud provider's control over the fix is bounded by the colocation operator's recovery timeline.
What to watch: whether Google's Monday, June 15 update on Delhi backbone capacity closes out the "for some" qualifier or extends it, whether the Google Cloud status page publishes a post-incident report naming the colocation operator and the network paths that were lost, and whether the June 17 Chennai peering target is met on the date Google set. For any business running on Google Cloud in India, the underlying question is now concrete: where are the third-party chokepoints in the region you are using, and what does your SLA actually cover when a facility you cannot see is the problem?