A fire at a third-party data center facility forced an emergency shutdown of networking equipment serving Google Cloud's Delhi region, and weeks later, customers across Delhi, Chennai, Mumbai, and nearby metros are still experiencing intermittent elevated latency and possible packet loss while Google works through a full recovery. It's a useful case study precisely because it isn't a dramatic multi-hour global outage — it's a slow-burn regional degradation caused by a facility Google doesn't fully control, and it's dragging on far longer than a typical cloud incident report suggests these things should.
What actually happened
The incident began with a fire at a third-party data center facility, which required an emergency power shutdown of networking equipment as a safety measure. That shutdown isolated a non-compute local Point of Presence (POP) serving Delhi, reducing available network capacity across the metro area. Because that POP handled network traffic — not compute workloads directly — the impact showed up primarily as degraded network performance rather than services going fully offline: elevated latency, non-optimal routing, and intermittent packet loss for traffic to and from Google's Delhi cloud region (asia-south2), with effects rippling out to nearby metros including Chennai and Mumbai as traffic rerouted around the affected capacity.
Google's public response has focused on three parallel efforts: optimizing backbone network capacity to route around the affected POP, expanding its own Delhi POP to reduce dependency on the damaged third-party facility, and migrating selected peering partners to alternate paths to improve regional resilience going forward. Even with that work underway, Google has continued to caution that customers may experience "slightly elevated latency" and non-optimal routing until the affected facility is fully restored — an unusually candid, ongoing acknowledgment that this isn't a resolved incident so much as a managed, gradually improving degradation.
Why this incident is more instructive than a typical outage
Most widely covered cloud outages are sharp and total: a region goes down, services return errors, the incident report gets published within days, and normal service resumes within hours. This incident is different in a way that's more representative of how infrastructure actually fails in practice — a partial, ongoing degradation caused by a facility outside the cloud provider's direct operational control, with a recovery timeline measured in weeks rather than hours, and no clean "all clear" moment customers can point to.
That distinction matters for how IT teams think about cloud resilience planning. Failover and redundancy planning tends to focus heavily on the sharp-outage scenario — if a region goes down, traffic fails over to another region, and service resumes. Partial, sustained degradation is a harder failure mode to plan for, because your monitoring needs to catch "10-20% of requests are slower than usual from this region" rather than "requests are failing outright," and your failover logic needs a threshold for when degraded-but-technically-working performance should trigger the same response as an outright outage.
How this compares to 2026's other high-profile cloud incidents
This incident is worth reading alongside two other major cloud reliability stories from earlier in 2026: a thermal event that took down AWS's us-east-1 region, and a VPC-origins configuration bug that disrupted AWS CloudFront. Both of those incidents were sharper and more total in their impact, but also resolved faster, with clear root-cause disclosures published within days. The Delhi incident's slower, partial, ongoing nature is arguably the more operationally challenging pattern for customers to manage, precisely because it doesn't force a decision the way a hard outage does. A total regional failure forces an immediate failover decision. A weeks-long "slightly elevated latency" degradation invites teams to keep tolerating it, quarter after quarter, without ever formally deciding whether that tolerance is actually appropriate for the SLAs their own downstream customers are depending on.
Aggregate data on cloud reliability in 2026 supports treating this as part of a broader trend rather than an isolated event: global public cloud network outages reportedly rose sharply week-over-week during the same general period, a pattern consistent with cloud infrastructure facing more frequent disruption generally as both AI-driven demand and aging third-party infrastructure dependencies compound each other. Treating each incident as a one-off, rather than tracking the aggregate trend across your vendor relationships, understates the planning case for building degraded-performance resilience into your architecture now.
The third-party dependency problem
Perhaps the most important detail in this incident is that the root cause sits at a third-party facility, not inside Google's own directly operated infrastructure. Major cloud providers build extensive redundancy into their own data centers, but regional network connectivity often depends on a web of third-party colocation facilities, peering points, and local infrastructure providers that aren't fully under the cloud provider's operational control — and aren't always visible to customers evaluating a region's reliability. A regional outage caused this way is a reminder that "which cloud provider" and "how reliable is this specific region" are related but distinct questions, and that a region's reliability depends partly on physical infrastructure your cloud vendor doesn't fully own or control.
For customers with latency-sensitive workloads specifically dependent on a single regional POP, this incident is a concrete illustration of a risk that's easy to underweight when evaluating cloud architecture: your provider's regional resilience commitments describe their own infrastructure, but real-world regional performance also depends on third-party facilities whose resilience posture you can't directly audit.
Why India-specific infrastructure risk deserves its own line item
India's cloud regions have grown extremely fast over the past several years, driven by strong domestic digital adoption, aggressive hyperscaler investment, and increasingly, data-residency requirements that push global companies to stand up dedicated India-hosted infrastructure rather than serving Indian users from Singapore or another regional hub. That rapid growth has generally outpaced the buildout of redundant, mature network infrastructure that older US and European regions have had decades to develop — more POPs, more peering diversity, more redundant physical paths between facilities. A single third-party facility fire being able to degrade an entire metro's cloud connectivity for weeks is a symptom of that maturity gap, not a one-off unlucky event, and it's a pattern likely to recur in other fast-growing regional cloud markets facing similar buildout pressure without matching investment in redundancy.
Companies serving Indian users, or with data-residency obligations requiring India-hosted infrastructure, should treat this incident as a specific argument for either provider-level redundancy (splitting traffic across more than one India-based provider or region where compliance permits) or, at minimum, an explicit conversation with their primary provider about the region's current network path diversity relative to more mature regions elsewhere in that provider's footprint. Assuming an emerging cloud region carries the same resilience profile as a mature one, simply because it's offered by the same global provider, is the specific assumption this incident undercuts.
What to actually do about this class of risk
If your organization runs latency-sensitive workloads dependent on a specific cloud region — particularly regions served by a smaller number of network paths or POPs than a mature US or EU region — this incident is worth using as a prompt to ask your cloud provider directly about network path diversity and third-party dependency for that specific region, not just their general SLA commitments. It's also worth building monitoring that specifically tracks latency degradation, not just availability, for critical regional dependencies, since a "slightly elevated latency" incident that drags on for weeks can meaningfully affect user experience or downstream SLAs without ever triggering a hard outage alert.
Where practical, workloads with strict latency requirements in regions served by fewer network paths should have an explicit degraded-performance response plan — a defined latency threshold that triggers failover or user-facing mitigation, separate from your standard hard-outage failover logic. Waiting for an outright regional failure to trigger your resilience response means absorbing weeks of degraded performance in incidents that look exactly like this one.
Practical takeaways
Ask your cloud provider directly about network path diversity and third-party facility dependency for any region hosting latency-sensitive workloads, rather than relying solely on their general uptime SLA. Build monitoring and alerting specifically for latency and packet-loss degradation, not just hard availability failures, since sustained partial degradation is a distinct failure mode from an outright outage and needs its own detection threshold. Define an explicit degraded-performance response plan — with a concrete latency threshold — for critical regional dependencies, so your team has a pre-defined trigger rather than deciding in the moment whether "still working, just slower" warrants failover. Treat regions served by fewer network paths or POPs as inherently higher-risk for this class of incident, and weight that in region-selection decisions for latency-sensitive workloads. And read cloud provider status updates for language like "may continue to experience elevated latency" as a signal the incident is ongoing and evolving, not resolved, even when the provider isn't actively updating a formal incident report.
Sharp, total outages get the incident reports and the headlines. Slow, partial degradations caused by infrastructure a cloud provider doesn't fully control are quieter, but they're arguably a more common — and more commonly under-planned-for — failure mode. This one is still playing out in Delhi, Chennai, and Mumbai weeks after the fire that caused it.