A fire that broke out at a New Delhi data center on June 5, 2026 has turned into one of the messiest cloud reliability stories of the year. Nearly three weeks later, Google Cloud customers across India are still dealing with degraded network performance, and at least one named client, travel and foreign-exchange firm Matrix Cellular, says it is struggling to recover more than two decades of business data. Google’s own status page still showed no fix as of June 23.
The trouble traces back to a blaze at the “Next-Gen Tower” facility in Greater Kailash-I, operated by STT Global Data Centres India (STT GDC) and linked to Singapore’s ST Telemedia and India’s Tata Communications. Delhi fire officials pointed to lithium battery units as the likely ignition source. What began as a localized equipment fire has become a case study in how exposed hyperscale cloud infrastructure still is to aging battery systems, third-party facilities, and single points of physical failure.
The Google Cloud outage in India is not an isolated event, either. It is the sixth major reliability incident to hit a top-three hyperscaler since January 2026, following outages at Microsoft Azure and Amazon Web Services triggered by causes ranging from lightning strikes to a fire linked to regional drone strikes in the Middle East. Together, they describe a cloud industry racing to build AI-scale capacity while its physical infrastructure keeps failing in increasingly public ways.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Caused the Google Cloud Outage in India
According to Reuters and multiple Indian outlets, the fire broke out on June 5, 2026 at the Next-Gen Tower data center in Greater Kailash-I, New Delhi. The facility is run by STT Global Data Centres India, a joint venture tied to Singapore’s ST Telemedia and Tata Communications, and it hosts infrastructure for several global technology companies, not just Google. Delhi fire authorities said the blaze most likely started in lithium battery units, the kind used in uninterruptible power supply (UPS) systems that keep servers running through grid outages. Lithium battery fires are notoriously hard to extinguish because the cells can reignite after being doused and generate their own oxygen while burning.
STT GDC’s early assessment, cited by Reuters, said the physical damage was contained to a single data hall and its associated infrastructure, while the rest of the facility kept running. No injuries were reported, and firefighters brought the blaze under control. But the electrical and networking equipment inside that one data hall told a different story. Tata Communications’ unit Novamesh described the damage in a letter seen by Reuters as “extensive,” adding that it was still hampering recovery efforts more than two weeks after the fire. An independent technical root-cause analysis was underway as of publication to confirm exactly how the batteries ignited.
Timeline: How a Local Fire Became a Three-Week Cloud Outage
Google Cloud’s own status page did not flag customer-facing problems until June 9, four days after the fire, when it reported that an emergency power shutdown had isolated a point of presence serving Delhi. From there, the Google Cloud outage rippled outward across three Indian metros and stayed unresolved far longer than a typical regional incident.
- June 5: Fire breaks out at the STT GDC Next-Gen Tower facility in Greater Kailash-I, New Delhi, reportedly in lithium battery and UPS units.
- June 9: Google’s incident page acknowledges network disruption, describing “a fire at a third-party data center facility” that forced an emergency power shutdown and isolated a local point of presence, as first detailed by the Times of India. Customers in Delhi, Chennai, Mumbai, and nearby metros report intermittent elevated latency and possible packet loss, concentrated among Hybrid Connectivity and Virtual Private Cloud customers.
- June 11: Google posts a follow-up status update as engineers work to reroute traffic away from the affected facility.
- June 14: The Register reports the network is still slow a week later, with Google saying it is augmenting Delhi backbone capacity and expanding Chennai regional peering.
- June 23: Google’s status page still lists no workaround, warning customers to expect elevated latency until the facility is fully restored.
- June 24: Reuters reports “extensive damage” at the site based on a Tata Communications letter, with client Matrix Cellular saying it is struggling to recover more than 20 years of data.
Nearly three weeks after ignition, this is no longer a short blip. It is a sustained cloud outage with a genuine data-loss angle, and it remains unresolved as this article goes to print on June 24. GCPDown’s incident archive would later log the disruption, which began June 5, 2026, as a medium-severity event that stretched a full 21 days and 12 hours before it was fully resolved.
Matrix Cellular and the Data Loss Fallout
Most cloud outages resolve within hours. What makes the Google Cloud outage in India different is the data loss angle attached to it. Matrix Cellular, a travel services and foreign exchange company, told Reuters it is struggling to recover more than two decades of operational and business data as a direct result of the fire.
Not every customer is in the same position, though. Tata Communications said it had already restored services for customers “who had subscribed for recovery and backup services,” while recovery for everyone else remains a work in progress. STT GDC, for its part, said it is supporting affected customers, including migrating some to alternate capacity where feasible.
That split matters. It underscores an uncomfortable truth about cloud infrastructure: resilience is only as good as the backup tier a customer actually paid for. Companies that treated disaster recovery as a checkbox rather than a line item are now facing the possibility of permanently losing decades of records, while those that paid for replicated backups are already back online. For IT leaders reading the headlines, that is probably the single most actionable lesson in the entire episode, arguably more useful than the fire itself.
Six Hyperscaler Incidents in Six Months
The Delhi fire would be a notable story on its own. In context, it is the sixth publicly documented major incident to hit AWS, Azure, or Google Cloud since the start of 2026, an unusually dense run of outages for companies that built their reputations on relentless uptime. The pattern is not new for Google Cloud specifically, either: StatusGator’s tracking counted 38 separate Google Cloud outages between January and June 2025 alone, and a global Google Cloud outage on June 12, 2025 knocked out 54 products for more than seven hours, according to a NetworkWorld report published that same month.
| Date | Provider | Region | Root Cause | Duration / Impact |
|---|---|---|---|---|
| Feb 7-8, 2026 | Microsoft Azure | West US | Electrical failure in an on-site transformer | ~20 hours; utility power not fully restored until the next day |
| Mar 1-2, 2026 | AWS | ME-CENTRAL-1 (UAE) / Bahrain | Fire after objects struck the facility amid regional strikes | ~60 services down; AWS said recovery would take “at least a day” |
| Apr 24, 2026 | Microsoft Azure | East US | Resource provisioning and scaling failures | ~12 hours (11:30-23:22 UTC) |
| May 7-8, 2026 | AWS | us-east-1 | Thermal event and power loss at a single data center | ~28-hour single-availability-zone failure; 150+ dependent services affected |
| May 29-30, 2026 | Microsoft Azure | West US 2 | Severe thunderstorm and lightning-linked power disturbances | ~15-22 hours degraded; Azure OpenAI Service down separately for ~7 hours |
| Jun 5-24+, 2026 | Google Cloud | Delhi point of presence / India | Fire in lithium battery and UPS units at a third-party facility | Ongoing, nearly 3 weeks; no workaround as of June 23 |
Two things stand out. First, the causes are almost all physical: power equipment, weather, and in one case, warfare, rather than pure software bugs, a pattern also visible in Microsoft’s own published status history for its February and May incidents. Second, no single provider has a clean record so far this year. AWS, Azure, and Google Cloud have each had at least one major incident in the first half of 2026, which makes it harder for enterprise buyers to treat any single hyperscaler as the safe default. Readers who want the deeper breakdown of AWS’s own rough stretch can see our earlier coverage of the US-West-2 incidents, and CRN has been tracking the full list of AWS’s biggest 2026 stories as they unfold.
When Geopolitics Hits the Cloud: The AWS UAE Fire
The most dramatic entry on that list is not a weather event or a battery fire. On March 1-2, 2026, AWS’s ME-CENTRAL-1 region in the United Arab Emirates went down after physical objects struck a data center facility amid a wave of Iranian strikes across the Gulf following earlier US and Israeli attacks on Iran. AWS did not initially confirm what had hit its infrastructure, but its language left little doubt about the severity.
“One of our Availability Zones was impacted by objects that struck the data centre, creating sparks and fire.”
AWS, in a statement reported by 404 Media
AWS urged customers to move workloads elsewhere while it fought the fire.
“For customers that can, we recommend failing away to another AWS Region at this time.”
AWS, quoted by Nairametrics
Recovery, AWS warned, would not be quick.
“We anticipate that recovery will require at least a day, as it involves repairs to cooling power systems coordination with authorities, and thorough assessments to guarantee the safety of our operators.”
AWS, in a statement reported by 404 Media
In the meantime, AWS kept customers updated as the situation developed.
“We are actively working to restore power and connectivity, at which time we will begin to work to recover affected resources. As of this time, we expect recovery is multiple hours away.”
AWS, quoted by Nairametrics
Roughly 60 services tied to the affected region went down, disrupting web traffic across the UAE and Bahrain. It was a stark reminder that hyperscale cloud regions, no matter how redundant on paper, still sit inside physical buildings that outside forces can strike, entirely unrelated to software.
The Common Thread: Physical Infrastructure Risk in the AI Era
Line up the six incidents and a pattern emerges that has little to do with code. Azure’s February outage in West US came from an electrical failure in an on-site transformer that knocked out utility power for the better part of a day. Its May 29-30 outage in West US 2 was caused by a severe thunderstorm that triggered utility power disturbances across multiple data center facilities, keeping services degraded for hours and separately knocking out the Azure OpenAI Service. AWS’s May 7-8 outage in us-east-1 stemmed from a thermal event that cut power at a single Northern Virginia data center, a roughly 28-hour single-availability-zone failure that still managed to take down more than 150 dependent services. And now Google Cloud’s India outage traces back to a lithium battery fire.
None of these are software bugs in the traditional sense. They are power, cooling, and physical-plant failures, the unglamorous infrastructure underpinning every AI chatbot and enterprise workload running in the cloud. That is not a coincidence. Cloud providers are racing to cram more power-hungry AI hardware into existing facilities and building new ones faster than ever, and AI-related cloud spending has grown from roughly 8% of total cloud spend in 2023 to about 19% in 2026. More power density means more heat, more battery capacity, and more stress on electrical systems that were not designed for today’s load. When something goes wrong with the physical plant, in Delhi, in Virginia, or in the Gulf, it does not stay a facilities problem. It becomes a cloud outage that customers around the world can feel, a lesson Google Cloud relearned on July 15, 2026, when a cooling failure in its europe-west4-a zone triggered a 12-hour, 28-minute outage for Google Cloud VMware Engine, NetApp Volumes, and Bare Metal Solution.
Market Impact: India’s $17.5 Billion Cloud Bet
The timing is awkward for Google Cloud specifically. India’s public cloud market is in the middle of a growth spurt that every hyperscaler is chasing. Gartner-backed figures reported by Business Standard put India’s end-user spending on public cloud services at $17.5 billion in 2026, up 28.1% from $13.7 billion in 2025, with infrastructure-as-a-service growing 40% and platform-as-a-service growing 25.4% this year alone. Mordor Intelligence puts the broader India cloud computing market, public and private combined, at $26.43 billion in 2026, up from $21.82 billion in 2025, with public cloud accounting for close to 74% of that spend. That is a steep climb from the roughly $13.5 billion by 2026 that IDC originally forecast back in 2022, underscoring how much faster India’s cloud demand accelerated than early estimates assumed.
| Source | 2026 Estimate | Growth Rate | Scope |
|---|---|---|---|
| Gartner (via Business Standard, June 2026) | $17.5 billion | +28.1% YoY from $13.7B in 2025 | Public cloud end-user spending |
| Mordor Intelligence | $26.43 billion | 21.1% CAGR, 2026-2031 | Total cloud computing (public + private) |
| IDC (2022 forecast, via ET CIO) | $13.5 billion | 24% CAGR, 2021-2026 | Public cloud services, original estimate |
| IDC (Dec 2022, via Business Standard) | $13 billion | 23.1% CAGR, 2021-2026 | Public cloud services, independent estimate |
| IDC (Dec 2024 update) | $25.5 billion by 2028 | 24.3% CAGR, 2023-2028 | Public cloud services, revised trajectory |
The spread between those estimates is wide, from roughly $13 billion to more than $26 billion, mostly because analysts disagree on scope. Some measure public cloud spending alone, while others fold in private and hybrid deployments. What every estimate agrees on is direction: India’s cloud spending keeps getting revised upward, not down, which is exactly why AWS, Azure, and Google Cloud have all been racing to add capacity and win large Indian enterprise and government contracts. For more on how that growth race looks from the vendor side, see our coverage of Google Cloud’s recent growth numbers heading into earnings season. A three-week outage with a public data-loss story attached is exactly the wrong kind of headline to have in the middle of that race. It will not show up in this quarter’s cloud revenue, but IT buyers evaluating vendors for multi-year contracts do remember stories like this one, especially with a named customer on record saying it may have lost decades of records.
Competitive Comparison: AWS vs Azure vs Google Cloud on Reliability
Even before the fire, Google Cloud was the smallest of the three hyperscalers by both revenue and market share. AWS generated roughly $115 billion in FY2025 revenue against Azure’s approximately $100 billion and Google Cloud’s roughly $48 billion. Global market share estimates for early 2026 put AWS around 28-31%, Azure around 21-25%, and Google Cloud around 12-14%, depending on which analyst firm is doing the counting and which quarter they are measuring.
What stands out in 2026 is that reliability, not just price or AI features, has become a genuine differentiator again. Azure has had two major documented incidents in the first half of the year, tied to a transformer failure and a lightning strike respectively. AWS has had two as well, one tied to a thermal event in Virginia and the dramatic UAE fire linked to regional strikes. Google Cloud’s own numbers have not helped its case: ServiceAlert estimated Google Cloud uptime at just 95.7% in February 2026, with a full day showing issues that month, and Google’s own Service Health page separately logs a Vertex AI Gemini API incident on February 27, 2026 that lasted 1 hour 58 minutes. Google Cloud’s India outage is its most significant publicly documented 2026 incident, and it is also the slowest to resolve, stretching close to three weeks with no firm end date as of June 24. Speed of recovery, not just the initial cause, is shaping up to be the real differentiator among the three going forward.
Historical Context: Cloud Outages Are Not New
Hyperscale cloud outages have a long history, and none of the 2026 incidents come close to matching the granddaddy of them all: AWS’s December 7, 2021 outage in us-east-1. That incident, triggered by automated scaling activity that caused abnormal behavior across AWS’s internal network, knocked out the AWS Management Console alongside API Gateway, Fargate, Lambda, and EC2 APIs for more than seven hours, taking a long list of consumer apps and enterprise dashboards down with it. Google Cloud has had its own taste of that scale of disruption: during the June 12, 2025 outage, Downdetector logged 14,729 U.S. Google Cloud reports by 2:32 p.m. ET, per Reuters, and more than 13,000 reports around 11:30 a.m. PT, per CNBC, while downstream, Spotify users filed roughly 46,000 outage reports and Discord logged 10,992 U.S. reports at the peak, Reuters reported.
What is different in 2026 is not really the frequency of outages. It is what rides on top of the infrastructure now. Five years ago, a regional AWS outage mostly meant broken websites and annoyed consumers. Today, enterprises have layered agentic AI workflows, real-time fraud detection, and customer-facing chatbots directly onto these same regions, often without the multi-region redundancy that would have been standard practice for mission-critical systems a decade ago. A three-week degraded state in India does not just mean slow page loads. It means AI inference pipelines, VPN-dependent hybrid connectivity, and backup jobs running in a persistently degraded state for weeks, not hours.
How Enterprises Are Responding: Multi-Region and Multi-Cloud Playbooks
The immediate lesson coming out of Delhi is not subtle: single-region dependency is a liability. AWS said as much directly during its own UAE fire, telling customers to fail away to another region while it fought the blaze. Enterprises that had already built multi-region failover into their architecture could act on that advice within minutes. Those that had not were stuck waiting.
A basic multi-region health-check pattern, of the kind resilience-focused teams are now retrofitting into existing deployments, looks something like this:
#!/bin/bash
# Simple multi-region failover check for a Google Cloud VPC-backed service
REGIONS=("asia-south1" "asia-southeast1" "us-central1")
for region in "${REGIONS[@]}"; do
status=$(gcloud compute regions describe "$region" --format="value(status)" 2>/dev/null)
if [ "$status" == "UP" ]; then
echo "Routing traffic to $region"
break
else
echo "$region unavailable, checking next region"
fi
doneThat kind of scripted failover is a small piece of a much larger discipline: treating every region, and every third-party facility a cloud provider leases space from, as a potential single point of failure. Teams evaluating their Kubernetes scaling and failover posture may also want to look at how tools compare in our Karpenter vs Cluster Autoscaler vs KEDA breakdown, since scaling policy and regional failover are increasingly the same conversation. Enterprises with real backup and recovery subscriptions, the kind Tata Communications says it was able to restore quickly, are the ones sitting comfortably right now. Everyone else is learning that lesson in public, mid-quarter.
Regulatory and Business Risk Implications for India’s Digital Infrastructure
The Delhi fire also lands at an awkward moment for India’s digital infrastructure ambitions. The government has spent years courting hyperscaler investment and positioning India as a global cloud and AI hub, and a prolonged, high-profile outage tied to a third-party data center raises the kind of business-continuity questions that enterprise risk committees take seriously, especially for regulated industries like financial services and telecom, where Matrix Cellular itself operates. Expect renewed scrutiny of data center fire safety standards, backup power design, and disclosure timelines from operators, even without a specific new rule tied directly to this incident yet.
For global technology companies deciding where to locate the next wave of AI and cloud capacity, incidents like this one become part of the risk calculus alongside power availability, tax incentives, and talent pools. India’s cloud market is growing fast enough that a single fire will not derail it, but it does add friction to conversations about which facilities get the most latency-sensitive, mission-critical workloads.
What This Means for FinOps and Cloud Architecture Teams
For cloud cost teams already fighting to control AI-driven spend, this outage adds a new line item to the resilience-versus-cost debate. Multi-region and multi-cloud redundancy is not free. It means paying for compute and storage that sits idle most of the time, precisely the kind of spend that FinOps teams have spent 2026 trying to eliminate amid reports that cloud waste has climbed as high as 29% industry-wide. The Delhi outage is a real-world argument for why some of that waste is actually insurance. Finance teams evaluating cloud architecture decisions, and the cost-visibility tooling behind them, will need to weigh idle standby capacity against the cost of a three-week regional degradation with a customer-facing data-loss story attached.
Predictions: Where Cloud Reliability Goes From Here
Frequently Asked Questions
What caused the Google Cloud outage in India?
A fire at the STT Global Data Centres India “Next-Gen Tower” facility in Greater Kailash-I, New Delhi, on June 5, 2026. Delhi fire authorities said it likely started in lithium battery units used in the facility’s backup power systems, though a full technical root-cause analysis was still underway as of late June.
How long has the Google Cloud outage in India lasted?
As of June 24, 2026, the disruption has stretched nearly three weeks. Google’s status page still reported no workaround as of June 23, and customers were warned to expect elevated latency until the facility is fully restored.
Which Google Cloud services were affected?
Google said the fire mainly affected a subset of Hybrid Connectivity and Virtual Private Cloud customers, with network traffic from Delhi, Chennai, Mumbai, and surrounding metros experiencing intermittent elevated latency and possible packet loss.
Did any companies lose data because of the outage?
Travel and forex company Matrix Cellular told Reuters it is struggling to recover more than two decades of operational and business data. Tata Communications says it has already restored customers who had subscribed to backup and recovery services, with recovery for other affected customers still in progress.
How does this compare to AWS and Azure outages in 2026?
It is the sixth major documented incident across the three leading hyperscalers since January 2026, following two Azure incidents (a transformer failure in February and a lightning-triggered outage in May) and two AWS incidents (a thermal event in Virginia in May and a fire linked to regional strikes in the UAE in March).
Is Google Cloud down right now?
As of this article’s publication on June 24, 2026, Google Cloud’s core global services are operational, but customers with resources tied to the affected Delhi point of presence may still experience elevated latency until the facility is fully restored. Check Google’s official Cloud status page for the latest updates.
Will affected customers get SLA credits?
Neither Google nor Tata Communications has publicly detailed a compensation or SLA credit structure specific to this incident as of publication.
What should businesses do to reduce this kind of risk?
Build multi-region failover into critical workloads, confirm what tier of backup and disaster recovery service is actually under contract, and treat any single data center, including ones leased from third parties like STT GDC, as a potential point of failure rather than a guarantee.
