Google Cloud India Disruptions Persist Days After Delhi Data Center Fire

Google Cloud customers across India continue to experience intermittent latency and packet loss after a fire at a third-party Delhi data center forced an emergency shutdown of networking equipment on June 9, isolating a local Point of Presence and degrading regional capacity.

In a status update published June 11, Google confirmed that network traffic originating from Delhi, Chennai, Mumbai, and surrounding regions remains affected. The root cause was the isolation of a Delhi Point of Presence (POP), which reduced total network capacity serving the metro area and forced Google to redirect traffic to alternate paths.

Although rerouting has provided partial relief, Google acknowledged that Hybrid Connectivity and Virtual Private Cloud customers may continue to see latency spikes where rerouted demand is pushing against the limits of remaining capacity across Indian metros and regional ISPs. Initial mitigation steps have shown improvement for some customers, but conditions are not yet fully normalized.

Google's recovery work is running on several parallel tracks: optimizing backbone capacity, expanding the Delhi POP, and shifting selected peering partners to alternative interconnects to improve regional resilience. The company said customers should expect "slightly elevated latency" and non-optimal routing to persist until the affected third-party facility is back in service.

Why this matters

For cloud operators, managed service providers, and enterprises running India-facing workloads on Google Cloud, the incident highlights a structural risk: dependency on third-party colocation facilities for critical network edge infrastructure. A single POP isolation was sufficient to degrade service quality across multiple major metros simultaneously, with effects rippling across both direct VPC customers and those relying on Hybrid Connectivity links such as Dedicated Interconnect or Partner Interconnect circuits.

The multi-day recovery timeline is also notable. While Google has rerouted traffic and is expanding capacity, the underlying fix — restoring the fire-damaged facility — remains incomplete, meaning the event is not a brief spike but a sustained degradation event. Customers with latency-sensitive workloads, such as real-time APIs, financial transaction processing, or low-latency database replication between on-premises infrastructure and Google Cloud, are most exposed.

The incident adds to a record of Google Cloud disruptions that infrastructure planners in the region will need to account for in resilience planning. Google has not disclosed the name of the third-party facility operator involved, nor has it provided an estimated restoration timeline beyond the June 12 update commitment.