Google Cloud’s outage proves resilience is a business decision

A cloud outage is no longer just an engineer’s bad morning. When a failure at one provider interrupts banking, court video and public services, it becomes a test of how much digital infrastructure a society has quietly concentrated in one place.

On October 20, Google Cloud experienced a disruption in its europe-west2 region, with the europe-west2-b zone notably affected. Reuters reports that users reported problems involving Lloyds, HSBC and Rightmove, while other reports named Revolut, ING Germany and Halifax among services experiencing issues. Google’s incident page said services were unavailable in the affected zone and that some services across the region might experience elevated errors. The outage has since eased, but the important question is not whether Google eventually restored service. It is why so many businesses were exposed to the same failure at all.

“The cloud” is not a strategy when everyone uses the same provider

Cloud computing is often sold as an escape from fragile in-house infrastructure. That promise is real: a large provider can offer geographic distribution, automated recovery and operational expertise that many companies could not reproduce economically. Google’s own disaster-recovery guidance is explicitly built around designing workloads to withstand cloud infrastructure outages.

But resilience is not the same as availability. A customer can be running in a modern cloud region and still depend on a single provider, a single region, a single zone or a small set of shared services. The result is a system that looks distributed on an architecture diagram while remaining concentrated in practice.

That is the central lesson from this incident. The failure did not need to take down every Google Cloud service worldwide to cause broad disruption. It only needed to reach enough customers whose applications, payment flows or public-facing systems were tied to the same regional infrastructure. A cloud platform can be enormous and still create a narrow point of failure for the companies built on top of it.

This is why the phrase “move to the cloud” has become too imprecise to be useful. The relevant question is not whether a company uses cloud infrastructure. It is how many independent paths remain when that infrastructure becomes unavailable.

Redundancy is expensive—and pretending otherwise is worse

The uncomfortable part is that the fix is not simply another checkbox in a deployment tool. Genuine resilience may require a second cloud provider, duplicated data, independent identity systems, alternative payment routes, tested failover procedures and teams capable of operating under degraded conditions. Those measures cost money and add complexity.

They can also make systems harder to manage. A multi-cloud design may reduce dependence on one vendor, but it can introduce incompatible services, more complicated monitoring and additional security work. Replicating a database across providers is not automatically safer if the replication process, credentials or recovery plan still share a common dependency.

So the right response is not a reflexive demand that every company abandon Google Cloud. That would be as simplistic as assuming a single provider is always sufficient. The sensible question is proportionality: what happens if this service is unavailable for hours, and what is the financial or public cost of that interruption?

For a low-stakes internal tool, accepting concentration may be perfectly rational. For banking access or a public service, the answer should be different. The customer—not only the cloud provider—has to decide whether the savings and convenience justify the exposure.

A regional failure can become a public infrastructure problem

The banking disruption makes the issue especially visible because customers do not experience cloud architecture as an abstract technical choice. They experience it as a card that does not work, an account they cannot access or a service that stops responding. The BBC reported that the outage affected courts, banks and other online businesses, a combination that turns a vendor incident into a question of institutional resilience.

That does not mean Google alone is responsible for every downstream failure. Businesses choose how to architect their systems, and the available documentation does not establish that every European bank relied on the same design. The more defensible conclusion is narrower—and more serious: a regional Google Cloud disruption was capable of affecting multiple essential services because many organizations had accepted a common dependency.

There is also a warning against treating past uptime as a substitute for recovery planning. Google Cloud has experienced other incidents, including a Cloud Storage disruption in us-central1 on October 8, 2026, when uploads and writes faced elevated latency and errors for 12 hours 30 minutes. IncidentHub’s account says Google’s preliminary explanation involved resource exhaustion after a traffic-sorting optimization, alongside a separate database issue. Different regions and causes do not prove that every workload is at risk in the same way, but they do undermine the comforting idea that a major platform can be treated as an invisible utility.

Customers should pay for independence where failure matters

The cloud industry’s great convenience is also its political and economic weakness: it lets thousands of organizations outsource difficult infrastructure decisions to a few providers. That is efficient until the outsourced decision becomes a shared failure mode.

Our view is that regulators and boards should stop asking only whether a provider has impressive availability figures. They should ask whether a critical service can operate when its primary region, provider or shared control plane cannot. The answer should be documented, tested and funded—not left to a disaster-recovery slide deck.

Google Cloud remains a powerful platform, and this outage does not make it uniquely irresponsible. It does show that resilience has a price, and that price cannot be wished away by calling infrastructure “cloud.” For noncritical workloads, concentration may still be the smart bargain. For banking and public services, however, independence is not wasteful duplication. It is part of the service itself.