What Google’s Status Update Confirmed

Google Cloud published a status update at 11:22 PDT on June 9, confirming that a fire at a third-party facility had required an emergency power shutdown of networking equipment. The shutdown isolated a non-compute local Point of Presence (POP) in Delhi, reducing available network capacity in the metro area.

Google rerouted traffic from the affected facility, but the rerouting itself introduced secondary problems. Hybrid connectivity and VPC customers experienced intermittent latency spikes as demand exceeded capacity across rerouting paths. As of June 10, Google had not published a timeline for full restoration of the affected POP.

Google did not name the facility. Multiple Indian technology outlets identified it as a Tata Communications installation in Greater Kailash, New Delhi. The Delhi Fire Service dispatched 11 fire engines to the building; the fire was contained by around 7:00 AM. Two firefighters sustained minor injuries; no civilian casualties were reported. The fire originated in a battery room on the third floor and covered approximately 200 square feet.

Region vs. POP: Two Different Things on the Same Map

Cloud providers operate two distinct categories of infrastructure, and both appear on regional footprint maps without clear differentiation.

A compute region is a cluster of owned data centers where customers run virtual machines, store data, and deploy applications. Google Cloud operates two compute regions in India: asia-south1 in Mumbai and asia-south2 in Delhi. These are owned facilities with independent power and redundant connectivity.

A network POP is a different category. POPs are edge nodes that handle network traffic routing and peering. They connect users to the compute region but do not run workloads themselves. Providers routinely locate POPs in third-party colocation facilities, because leasing space for a router rack is faster and cheaper than building a full data center. Google, AWS, and Azure all operate POPs in leased facilities globally.

The Delhi fire hit a POP, not a compute facility. The compute kept running. But because user traffic routes through that POP before reaching the region, performance degraded for customers across connected metros.

What Indian Hosting Customers Are Teaching the Global Hosting Industry

Why Three Cities Failed When One Facility Burned

A POP in Delhi handles traffic not only from Delhi users but from interconnected cities sharing the same regional backbone. When the Delhi POP was isolated, traffic from Mumbai and Chennai that would normally route through the Delhi node had to be redirected, adding latency at each step. Google’s own status update documented the cascade: rerouting changes caused secondary issues for hybrid connectivity and VPC customers. A single third-party facility failure in one city produced performance degradation across three metropolitan areas.

Billions Committed, But Infrastructure Is Still Being Built

India is one of the fastest-growing cloud markets in the world. The data center colocation segment alone is projected to reach $7.31 billion in 2026, up 25.5% year on year. Announced hyperscaler investment across the next five years totals an estimated $60 to $70 billion, with Google having committed $15 billion, AWS $8.3 billion, and Microsoft $3 billion in Azure capacity.

These commitments describe future capacity. The Delhi incident reflects the current state: network routing in growth markets routinely relies on third-party colocation, because establishing a router in a leased facility is faster than building a region. The owned infrastructure follows later.

India’s Digital Personal Data Protection Rules, passed in 2025, require certain categories of data to be stored and processed within India. That regulatory pressure pushes enterprises toward India-based cloud infrastructure. When enterprises select a provider based on regional presence, the assumption is often that the entire stack, including network routing, is within that footprint. The Delhi incident is a concrete example of where that assumption breaks down.

What Buyers in Data-Localized Markets Need to Verify

The Delhi incident is not evidence that Google Cloud is unreliable. It is evidence that “regional presence” is not a single, uniform thing. A 200 square foot battery room fire in one leased building should not degrade cloud performance across three cities and generate cascading latency for VPC customers. That it did is an architectural fact about how network presence is built in growth markets, and it applies to all three major hyperscalers, not only Google.

Three questions worth raising before assuming full regional resilience:

  • Is the network routing infrastructure owned or third-party co-located? A fire or power failure in a leased facility is outside the provider’s direct control. Providers are not obligated to disclose which facilities in their POP network are third-party.
  • Does the SLA cover network performance or only compute availability? Google’s compute stayed operational throughout this incident. Customers on compute-only SLAs had no contractual basis for a claim, even though they experienced service degradation.
  • Does the provider distinguish POP failures from region failures in its incident documentation? Google’s status page described the affected asset as a “non-compute local POP,” which is technically precise. But buyers without that background may not recognize the distinction or its implications for workload design.