A week after a fire hit its network, Google Cloud India is still running slow

A physical infrastructure failure has exposed how thin the redundancy margins are for cloud providers operating in fast-growing but infrastructure-constrained markets.

Written by Mara Voss · Bureau Tech · Jun 18, 2026

The fire is not the story. The week after is.

A fire struck Google Cloud India's network infrastructure, and by the time a week had passed, the network was still running below normal performance. That second fact matters more than the first.

Fires happen. Data centers and the fiber plants that feed them are physical objects in a physical world. What a prolonged degradation window reveals is that the redundant capacity available to reroute traffic — the backup paths, the spare wavelengths on optical links, the headroom in peering arrangements — was not enough to fully absorb the load that the damaged segment had been carrying.

What 'network slowdown' actually means

In cloud networking, a slowdown after a physical cut typically means one of a few things: traffic is being rerouted over longer paths (adding latency), rerouted paths are congested (adding both latency and packet loss), or some services are being rate-limited to protect core functionality. Any of these outcomes degrades the experience for end users and, more critically, for enterprise workloads that depend on consistent round-trip times.

Latency-sensitive applications — financial transaction processing, real-time analytics, VoIP, gaming backends — are the first to show symptoms. But even batch workloads suffer when TCP throughput drops because of elevated packet loss on a congested alternate path.

Why India is a hard market for redundancy

India's cloud market is growing rapidly, but the physical infrastructure supporting it — long-haul fiber routes, submarine cable landing stations, carrier-neutral colocation — is still catching up to demand. That asymmetry creates a structural risk: customer workloads scale faster than the underlying physical plant can be diversified.

Google Cloud operates multiple regions in India, but regional diversity only helps if the failure is contained to one region and inter-region bandwidth is sufficient to absorb the overflow. A network-layer event that affects connectivity between regions or between a region and its upstream transit providers can degrade performance across a wider blast radius than a single datacenter failure would.

What enterprises should take from this

If you are running production workloads in Google Cloud India — or any single cloud region in a market with constrained physical infrastructure — this incident is a useful prompt to audit your architecture.

Specifically: does your failover configuration actually route to a different physical network path, or does it route to a different logical zone that shares the same upstream fiber? Those are not the same thing, and many architects conflate them.

Multi-cloud and hybrid configurations add operational complexity, but they also add genuine physical diversity when implemented correctly. The tradeoff is real in both directions.

Elsewhere in Asia-Pacific infrastructure

The same week brought two other infrastructure-adjacent stories worth noting. Japan's H-II Transfer Vehicle — the country's autonomous cargo spacecraft used to resupply the International Space Station — returned to operational status after a stand-down period, a reminder that space logistics infrastructure has its own reliability curve.

Zoho, the Indian enterprise software company, disclosed that it has been building its own server hardware rather than purchasing from standard OEM vendors. That move mirrors what hyperscalers like Meta and Google did a decade ago: once you reach sufficient scale, custom silicon and custom chassis economics beat catalog hardware. Zoho is not at hyperscaler scale, but the decision signals both cost pressure and a desire for supply-chain control that is increasingly common among large software-first companies.

Korea also posted record technology export figures for the period, driven primarily by semiconductor shipments — a data point consistent with the ongoing global demand for memory and logic chips that has defined the sector since 2024.

Key takeaways

Google Cloud India's network remained degraded for at least seven days following a fire that damaged physical infrastructure.
Prolonged slowdowns after a physical event indicate that spare capacity or alternate routing in the region was insufficient to fully compensate.
The incident is a reminder that cloud SLAs (service-level agreements) are bounded by physical constraints — fiber, power, and cooling — that software cannot abstract away.
Enterprises running latency-sensitive workloads in India should review their multi-region or hybrid failover configurations in light of this event.
The broader Asia-Pacific week also included Japan's HTV cargo spacecraft returning to service and Zoho building its own server hardware — both pointing to a regional push toward infrastructure self-sufficiency.

FAQ

How long did Google Cloud India's network degradation last?

According to reporting by The Register, the network remained slow for at least a week after the fire that caused the initial damage. The exact restoration timeline was not fully confirmed at time of publication.

Does Google Cloud have multiple regions in India?

Yes. Google Cloud operates more than one region in India. However, regional redundancy only mitigates a failure if the failure is isolated to one region and inter-region connectivity is unaffected. A network-layer event can span multiple regions depending on where in the topology the damage occurs.

What is an SLA and does it cover slowdowns like this?

An SLA, or service-level agreement, is a contractual commitment from a cloud provider about uptime and performance. Most cloud SLAs cover full service unavailability and offer credits when availability drops below a defined threshold. Partial degradation — where services are reachable but slow — often falls into a gray zone that may not trigger SLA credits, depending on how the agreement is written.

What is Zoho doing with DIY servers?

Zoho, the Indian enterprise software company, has been building its own server hardware rather than buying from standard OEM vendors. This is a cost and supply-chain control strategy that large technology companies have pursued at scale for years. It reduces dependence on third-party hardware vendors and can lower per-unit costs once internal volume justifies the engineering investment.

Why does physical infrastructure matter for cloud reliability?

Cloud services run on physical hardware connected by physical fiber. Software-defined networking and virtualization can reroute traffic and mask some failures, but they cannot create bandwidth or reduce the speed of light. When physical infrastructure is damaged, the software layer can only work with whatever physical capacity remains — and if that capacity is insufficient, users experience degraded performance regardless of the cloud provider's redundancy architecture on paper.

Citations

Fire burns Google Cloud India's network, which remains slow a week laterGoogle Cloud India's network remained degraded for approximately a week following a fire that damaged infrastructure.
The Register — Off-Prem coverage indexSecondary source aggregating The Register's infrastructure and cloud coverage, including the Google Cloud India incident and related Asia-Pacific stories.
The Register — PLUS items: Japan HTV, Zoho servers, Korea exportsThe same edition reported Japan's space cargo vehicle returning to service, Zoho building its own server hardware, and record technology exports from South Korea.