Fire slows Google Cloud traffic in India for a week

A fire at a third-party data center facility in Delhi forced Google Cloud to shut down network equipment June 9, isolating a local point of presence and reducing network capacity across parts of India.

Google said customers sending traffic to Google Cloud from Delhi, Chennai, Mumbai and nearby areas may see elevated latency, packet loss and suboptimal routing until workers restore the affected facility.

The outage did not hit compute capacity, according to Google’s status language. It hit the network path into Google Cloud. That distinction matters for customers: applications may stay online while users face slow page loads, failed API calls, timeouts and unstable links between systems.

Google said it has applied traffic mitigations and added work to expand Delhi backbone capacity. The company also said it plans more peering capacity in Chennai to support large Indian internet service providers, with that work targeted for June 17.

For banks, retailers, health platforms and SaaS vendors, the incident raises a plain operational question: can users reach the service when one metro-area network site fails?

Under the EU’s General Data Protection Regulation, companies that process personal data must protect confidentiality, integrity and availability under Article 32. A network disruption can create GDPR exposure if a company cannot keep personal-data services available or cannot prove it planned for known infrastructure risk.

The California Consumer Privacy Act, as amended by the California Privacy Rights Act, puts pressure on businesses and service providers to maintain reasonable security practices for personal information. The law does not turn a cloud latency event into a breach by itself, but customers still need vendor records, incident timelines and evidence that Google’s routing changes did not expose data.

India’s Digital Personal Data Protection Act adds another layer for companies serving Indian users. Firms that depend on cloud services need incident records, vendor notices and continuity plans that show who handled the disruption and how the company protected access to personal data.

Customers should pull logs for failed requests, packet loss, retry storms and queue backlogs from June 9 onward. They should also document user impact by region, because a regulator, auditor or enterprise customer will ask for facts rather than a status-page link.

Google’s next steps matter. Extra peering capacity can reduce congestion, but customers should not treat a single cloud provider’s network mitigation as their own resilience plan. Teams that run critical workloads in India should review multi-region routing, failover tests, DNS behavior and third-party dependency maps.

Google Cloud posts service information on the Google Cloud Service Health page. Customers with regulated workloads should save the relevant incident updates, match them to internal telemetry and preserve any support communications.

The fire shows how a non-compute facility can still disrupt cloud services. You can run healthy servers and still fail users if traffic takes a bad route into the platform.