Google Cloud says a regional incident in its London-based europe-west2 footprint disrupted more than 35 products for 7 hours and 52 minutes on October 20, rippling into U.K. banking apps and other digital services. The outage matters beyond one bad morning in London because it exposed a question many enterprises still answer too casually: when a cloud provider has redundancy, does a customer application actually fail over, or does it simply stop working in a more sophisticated way?
The incident began at about 06:08 GMT, according to Google Cloud Service Health, and the status record later described it as a power event in a London zone. The affected location was europe-west2, not a worldwide Google Cloud failure. But the service list was broad enough to touch both control-plane and data-plane dependencies, including Cloud Run, Compute Engine, Google Kubernetes Engine, Cloud Storage, BigQuery, Cloud SQL, Pub/Sub and VPC. That does not mean every one of those products was fully unavailable for the entire window. It does mean the disruption surfaced in enough layers of the stack to become a business problem for customers using that region.
The customer impact was concrete. The Associated Press reported disruptions affecting Lloyds, Halifax, HSBC and Revolut. Lloyds later said its app was operating again once the root issue had been resolved. Other contemporaneous reports tracked issues at consumer and public-facing services including Spotify, DPD and some NHS-related applications, though not every symptom has been independently tied to the same dependency path. In Revolut’s case, Google Cloud said customer money and data were safe; nothing in the supplied reporting points to a security breach or confirmed data loss.
What this outage actually shows
The easiest reading of a regional cloud incident is also the least useful: a major provider had a bad day. The more useful reading is operational. A single-zone power event can still become a multi-service business outage if customer architecture assumes that regional resilience automatically becomes application resilience.
That gap shows up in several common ways. A workload may be pinned to one zone even if the region contains multiple zones. A failover path may exist on paper but still require manual approval, DNS changes or database promotion. A service may be spread across zones while a key dependency — identity, secrets, queueing, API management or monitoring — remains effectively concentrated in the same region. Even well-designed applications can struggle if provider-managed control-plane functions and customer-managed recovery steps do not line up under real load.
This is why the headline fact is not only that europe-west2 had a power-related disruption. It is that one zone-level event appears to have surfaced simultaneously through compute, storage, networking, databases and managed platforms that many businesses treat as building blocks. When that happens, the customer question is less “Why did one region fail?” than “Which parts of our service can keep operating when one layer in that region starts returning errors?”
Google has said a fuller analysis will follow its internal investigation. That matters. The public record does not yet explain the exact topology involved, why so many services surfaced errors at once, how traffic was routed, or which recovery actions were automated versus manual. Those unknowns are precisely why businesses should resist broad conclusions about any single provider and instead use the incident to test their own assumptions.
Where provider redundancy stops and customer recovery starts
For cloud buyers, this is the distinction that should shape board slides, architecture reviews and incident drills: a cloud SLA is not the same thing as an application recovery plan.
Providers design zones, regional networks and managed services with their own availability targets. Customers decide how workloads are placed, how databases replicate, where state lives, how queues drain, and whether an alternate path can take traffic without breaking authentication, naming or compliance controls. A regional architecture that looks redundant in a diagram may still miss the business’s recovery-time objective if the failover is slow, partially manual or dependent on staff waking up and making the right call under pressure.
Multi-region design can reduce exposure to a single regional event, but it is not a free answer. It adds replication choices, write-consistency tradeoffs, egress cost, operational overhead and a larger blast radius for configuration mistakes. Some systems genuinely do not justify active-active deployment across regions. Others, especially customer banking, payments, healthcare and high-volume consumer services, may have business stakes high enough that a same-region-only recovery design is not the right risk posture.
The London incident sharpened that tradeoff because it happened in a major financial market and because the disruption reached apps ordinary customers touch first. Outages feel abstract until a bank login fails, a delivery platform stalls or a service desk loses visibility. That is when resilience architecture stops being an infrastructure concern and becomes a trust and continuity issue.
The failover audit to run now
The practical response is not to wait for the postmortem and then move on. It is to turn this incident into a dependency review:
- Workload placement: Are stateless services actually distributed across zones, and can schedulers move capacity without human intervention?
- Database and storage replication: Is failover zonal or regional? What are the real recovery-point and recovery-time expectations under write traffic?
- Identity, DNS and secrets: If authentication, certificate management, service discovery or DNS depends on the same region, can applications still start and reroute?
- Queues and backlogs: If Pub/Sub or other messaging layers degrade, what happens to retries, duplicate processing and backlog clearing after service returns?
- Operations access: Are monitoring, alerting, runbooks, bastion access and backups reachable outside the impacted region, or does the outage blind the responders too?
- Third-party dependencies: Which SaaS vendors, payment tools, analytics services or support platforms share the same regional cloud dependency even if they look separate on a procurement sheet?
Then ask the uncomfortable question many teams skip: has the failover path been tested under realistic production-like load, or only demonstrated in a tabletop exercise? A recovery design that works in staging can still miss its mark when databases are hot, queues are deep and customer traffic is arriving all at once.
For risk leaders, the right output is not a new slogan about multicloud or a blanket mandate for multi-region everything. It is a service-by-service view of what must survive a zonal event, what can tolerate a regional interruption, and what it costs to close the gap. The London outage is a reminder that resilience is not measured by how many redundant components exist inside a provider. It is measured by whether the business can keep serving customers when one of them fails.
By
By
By
By
By
By
By
