The Fire That Isolated a POP
Here's the thing about cloud infrastructure that nobody likes to admit: most of it lives in buildings you'll never see. Google Cloud's India backbone runs through third-party facilities, and on June 9th one of those buildings caught fire.
Per Google's own status page, the blaze forced an emergency power shutdown of networking equipment at a third-party data center. The result? A non-compute local Point of Presence — a POP in Delhi — got completely isolated. No compute was lost, but the network path through that node went dark.
That matters more than you'd think. POPs are the handshake points where Google's internal backbone meets external internet traffic. Cut one off, and all the packets that used to flow through it have to find another way. In a metro area like Delhi, where traffic density is enormous, there aren't many alternate routes that can absorb the load without breaking a sweat. The POP wasn't just a convenience — it was the primary gateway for a huge chunk of India-bound traffic.
What Customers Actually Felt
The symptoms were exactly what you'd expect from a degraded network path: intermittent latency spikes and packet loss. Not catastrophic — Google didn't go offline — but noticeable enough that engineers started opening tickets.
Traffic from Delhi, Chennai, Mumbai, and the surrounding regions all took a hit. If you were running anything latency-sensitive — real-time APIs, streaming workloads, even just snappy admin panels — you felt it. And the weird part? It was intermittent. Some hours were fine, others degraded. That inconsistency is what makes it so frustrating for operators trying to diagnose the problem on their end.
Google warned customers they'd be seeing "slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored." Translation: don't blame your app, blame the pipe. And the pipe isn't fixed yet.
Why a Week Later and Still No Fix
This is where the story gets interesting, because most people assume a POP isolation would be resolved in hours. Not this one.
Google has rolled out traffic mitigations — rerouting work, shifting load around the bottleneck. They say performance improved "for some Cloud customers." Note the qualifier: some. That tells you the mitigations are partial. They're buying time, not solving the problem.
The real work is happening at two levels. First, Google is augmenting its Delhi backbone capacity — essentially building more lanes on the highway while traffic is still backed up. Second, they're improving regional peering capacity in Chennai to help major Indian ISPs absorb overflow. Google's own timeline puts the Chennai work at completion by Wednesday, June 17th.
So even with both efforts in flight, full restoration is still days away. The fire didn't just damage one node — it exposed how thin the redundancy actually is in this part of the network. And that's a problem worth understanding, because it affects every team running production workloads in the region.
The Third-Party Risk Nobody Talks About
Every cloud provider leans on third-party facilities. It's cheaper, it scales faster, and it lets them focus capital on the compute and software layers that actually differentiate them. But third-party facilities are also single points of failure you can't fully control.
This fire is a textbook example. Google didn't own the building. They couldn't prevent the blaze. All they could do was react — shut down the equipment to protect it, reroute traffic, and hope the backup paths held. They didn't.
The lesson isn't that third-party hosting is bad. It's that your cloud provider's risk model is only as strong as its weakest facility. If you're running production workloads in India on Google Cloud, you should be asking: what happens if this POP goes dark? Do I have a multi-region failover? Am I routing through peering partners that bypass Google's backbone entirely?
Most teams haven't thought about it. This outage is a free wake-up call.
What to Watch Next
A few things to track as this plays out:
Chennai peering completion (June 17th). If Google hits that target, you should see measurable improvement for traffic flowing through South India. ISPs in the Chennai region will be the canary.
Delhi backbone augmentation. This is harder to gauge externally, but if latency from Delhi drops back toward baseline over the next few days, it's working.
Full POP restoration. Google hasn't given a date for when the Delhi facility will be back online. Until then, you're running on mitigations, not a fix.
If you're affected, the Google Cloud status page is still your single source of truth. And if this outage has you reconsidering your India footprint, now's the time to map out your own contingency paths — before the next fire.
The Bigger Picture for India Cloud
India is one of the fastest-growing cloud markets in the world, and Google has been investing heavily there. But this outage shows that growth doesn't always come with proportional resilience.
When you're scaling fast, you make trade-offs. You might prioritize speed-to-market over redundant architecture. You might lean on third-party facilities because building your own takes time and capital. And you might assume that what works in one region will work everywhere.
This fire breaks that assumption. Delhi is a critical node, not a peripheral one. When it goes down, the impact ripples across multiple cities and millions of users. That's not a failure of Google's engineering — it's a failure of the underlying infrastructure model.
The question for cloud operators isn't whether this will happen again. It's whether you're ready when it does.