Five Hours in London
At 06:08 UTC on October 20, Google Cloud's europe-west2-b zone, one of three availability zones in its London region, began experiencing problems that Google attributed to a power event. The zone stayed down for just over five hours, with Google's status page reporting the issue mostly mitigated by 14:03 UTC and full recovery following roughly 90 minutes later. Independent monitoring from Parametrix put the start slightly earlier, at 06:03 UTC, and recorded a slight rise in errors across the region's other two zones as well, a detail Google's own updates later acknowledged. Google said it would publish a full analysis after its internal investigation concluded.
The scope was wide for what Google initially described as a single zone issue. The company's status page eventually listed 38 affected products spanning compute, storage, databases, data processing, and networking, including BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, Google Kubernetes Engine, and Managed Service for Apache Kafka. Google's guidance to affected customers during the incident was to move workloads to another zone or region, advice that only helps customers who had already built that capability before the outage started.
Who Actually Got Hit
The named casualties span sectors that share little except a dependency on the same cloud region. Revolut reported card payments and ATM withdrawals as its worst-hit services, though it said customer money and data remained safe throughout. Lloyds and Halifax both reported app and online banking disruptions. DPD reported connection issues affecting deliveries. HM Courts and Tribunals Service lost its video hearing platform, and the NHS App reported what appeared to be localized disruption. Google has not confirmed which customers were affected, and the links between the outage and these companies rest on timing and public reports rather than Google's own confirmation.
That breadth, banking, logistics, justice administration, and healthcare all surfacing problems within the same window, illustrates a point that is easy to state abstractly and hard to internalize until it happens: a single zone's power failure does not stay contained to the obvious tenants. It ripples through every downstream system, internal and third party, that assumed the zone would simply stay up, from payment authorization to case management software that has nothing to do with Google Cloud by name but runs on it underneath.
Found Out From a Monitor, Not From Google
Parametrix's independent detection five minutes ahead of Google's own stated start time, and its 27 minute lag between Google's mitigation announcement and actual recovery, point to a structural issue beyond this one incident. Enterprises depending on a cloud provider's own status page as their primary incident signal are relying on that provider to notice, diagnose, and disclose its own failure in close to real time, with no independent verification built into the chain by default. Third party monitoring exists precisely because that assumption does not always hold, and this outage is a small but concrete example of the gap between a provider's self-reported timeline and what was independently observable.
The gaps here were measured in minutes, a reminder of scale rather than a sign that Google handled the incident poorly. A five minute early detection and a 27 minute late recovery confirmation, multiplied across an enterprise's full portfolio of cloud dependencies, is exactly the kind of blind spot that argues for independent monitoring on any system where minutes of undetected downtime carry real cost, rather than trusting a single vendor's dashboard as the sole source of truth.
Why Single Zone Dependencies Still Exist
The obvious response to an outage like this is to ask why any serious enterprise still runs customer-facing systems on a single zone or region in 2026, years after cloud providers started offering multi-region architecture as a standard option. The honest answer is cost and complexity. Multi-region deployments roughly double infrastructure spend for the redundant capacity, require data replication strategies that introduce their own consistency and latency tradeoffs, and demand engineering discipline to keep failover paths actually tested rather than theoretical. Many organizations made a rational tradeoff years ago to accept single-region risk in exchange for simpler architecture and lower cost, when outages of this scale were rarer.
That tradeoff deserves revisiting now, with the frequency of major cloud provider incidents affecting named enterprise customers rising across AWS, Azure, and Google Cloud alike over the past two years, even as each provider's individual uptime statistics remain high. A decision made when regional outages were rare events should be re-evaluated now that they recur as a regular line item in the industry's incident history, with the specific question being whether the cost of redundancy has grown faster than the cost of the next outage.
Multi-Region Is the Right Prescription, With Fine Print
Dr Amro Al-Said Ahmad's assessment of the incident, that resilience requires more than simply moving to the cloud and that multi-region deployment, workload portability, and tested disaster recovery are the real response, holds up well. Each of those three elements still carries its own cost and its own failure mode. Multi-region deployment without genuine data consistency testing can create a false sense of security that only surfaces during an actual failover. Workload portability across regions or providers adds ongoing engineering overhead to maintain. Disaster recovery plans that are not regularly tested tend to fail in unexpected ways, often at the worst possible moment.
The practical lesson from this outage centers on sequencing rather than slogans. Start by identifying which systems actually require multi-region resilience based on real business impact if they go down for five hours, rather than defaulting to either extreme of treating everything as critical or nothing as critical. Prioritize payment processing, authentication, and anything regulators would ask about after the fact, which is roughly the list of systems that actually failed at Revolut, the banks, and the courts service in this incident.
What to Actually Test Before the Next One
For technology leaders reading this as a warning rather than a news item, the actionable step is to run an actual failover drill on your most critical system within the next quarter, not to schedule a review of your architecture diagram. Confirm that failing out of your primary region does not silently depend on a shared control plane, shared identity service, or shared network path that also lives in that region, a common and often overlooked failure mode that undermines otherwise sound multi-region designs.
Pair that drill with an honest conversation about monitoring independence: if your primary signal for a cloud provider outage is that provider's own status page, add a third party or self-hosted check on your most critical endpoints so you are not finding out about your own downtime from the same company that caused it. Five hours is a survivable outage for most businesses. The next one, on a system assumed safe because it had not failed yet, is the one this incident should be used to prevent.
