Cloud Zone Outage Website Risk: What the Google Cloud London Failure Teaches
In this article7 sections
- What happened in the Google Cloud London outage
- Why a cloud zone outage website failure reaches beyond one server
- Where single points of failure hide for your site, email and checkout
- Choose how much failure you want to survive
- What to do now: a practical failover checklist
- What to watch next
- Frequently asked questions
A cloud zone outage website failure happens when the one data-centre location your site depends on loses power or networking, and everything hosted there goes with it. That is what the Google Cloud London incident of 20 October 2026 showed at scale. This article covers what happened, where your own single points of failure probably sit, and a practical plan to survive the same kind of event.
What happened in the Google Cloud London outage
Google Cloud said the incident started at 23:08 PT on Monday, which was 07:08 BST on Tuesday 20 October, and later blamed a "power event". Google's own wording was that a power event caused an outage within the europe-west2-b zone, and that the power event had been mitigated. That zone is one of three availability zones in Google's London region.
The knock-on effects were wide. Services including BigQuery, Compute Engine, Google Kubernetes Engine and Managed Service for Apache Kafka were affected, along with 27 others. Revolut lost card payments, transfers, ATM withdrawals, trading and sign-ins, and customers across Ireland and the UK reported problems from logging in to making card payments. A person familiar with the matter told Reuters the Revolut outage was related to the Google Cloud disruption. Revolut said customer money and data remained safe, and neither Google nor Revolut has mentioned a cyberattack.
The reports differ on scope. Google's status text named one zone, but The Stack noted that the incident seemed to affect all three zones in the region. Technology.org reports that Google described errors and intermittent network failures across the wider europe-west2 region. Treat "one zone" as the stated trigger, not a guarantee that everything else stayed healthy.
Why a cloud zone outage website failure reaches beyond one server
A cloud region is a geographic area, and a zone is a separate location inside it. Google's regions and zones documentation explains the distinction. Spreading workloads across zones protects you from one building failing, but only if your application is actually built to switch over. Many small sites are not: they sit on one server, in one zone, with one database.
A power fault is also a good reminder that "the cloud" is physical. Generators, switchgear and network equipment sit behind every virtual machine. When they fail, redundancy you did not configure does not exist. Technology.org notes the London region mainly serves customers in the UK and Ireland, so a business with local customers and one local host feels an event like this directly.
Where single points of failure hide for your site, email and checkout
Most people picture the web server. The weak spots are usually spread more widely, and they tend to share one location.
| Component | Typical single point of failure | What customers see |
|---|---|---|
| Website | One server or one zone | Error pages or timeouts |
| Database | One instance, no replica | Site loads but orders and logins fail |
| Checkout and payment hooks | Scripts or webhooks on the same host | Cards declined, orders lost |
| Business email | MX records pointing to one server | Bounced or delayed messages |
| DNS | All nameservers with one provider | Domain stops resolving |
| Backups | Stored on the same server or zone | Nothing to restore from |
The Revolut case is a clear example of the checkout problem: card payments, card top-ups and ATM withdrawals were partially unavailable. A small shop's version is a working homepage with a broken basket. See our guide to DNS outages and keeping email online for the DNS and email side.
Choose how much failure you want to survive
You do not need a bank's architecture. You need to decide which failure you can tolerate and for how long. The honest question is how much an hour of downtime costs you, then buy protection to match.
| Level of protection | Survives | Typical setup | Suits |
|---|---|---|---|
| Backups only | Data loss, not downtime | Off-site backups, tested restores | Brochure sites |
| Warm standby | Loss of one location | Second server in another location, regular data sync, manual DNS switch | Small shops, bookings |
| Active failover | Loss of one location, fast | Two locations, health checks, low-TTL DNS or load balancer | Revenue-critical sites |
| Multi-region | Loss of a whole region | Replicated data across regions | Larger teams |
For most small businesses, multi-region hosting is overkill, while a warm standby in a different location is realistic. Our shared vs VPS vs cloud vs dedicated comparison helps you pick the base platform.
What to do now: a practical failover checklist
- List what must stay up. Usually the site, checkout, email and DNS. Rank them.
- Find your single point of failure. Ask your host where your server physically sits and whether your backups share that location.
- Move backups elsewhere. Keep at least one copy outside the server and outside its data centre. Test a restore, not just the backup job.
- Prepare a second location. Build a standby server that can serve the site. Our data centers page lists locations and offers a latency test. If you need to copy the site over, free website migration can help.
- Lower your DNS TTL. A short TTL, such as a few minutes, lets you repoint the domain quickly. Do this before an incident, not during one.
- Use more than one nameserver set or provider if your DNS supports it. Check this with your DNS host.
- Protect email separately. Confirm your MX setup and how mail queues if your main server is down; our business email setup guide covers the basics.
- Write a one-page runbook. Who decides to fail over, what to change, how to tell customers.
- Rehearse once. Switch to the standby in a quiet period and note how long it takes.
Avoid assuming a provider's status page will tell you quickly. Technology.org records the early message as elevated errors and network failures, with the power cause named later.
What to watch next
The sources I read say the power event was the immediate cause but do not explain what triggered it, according to IBTimes. Watch for Google's full incident report. The useful details will be why the failure affected more than one zone, and how long recovery took. Use them to test your own assumptions: if a zone loss can still disrupt a region, check whether your standby is truly independent.
If you want a second location for your site or a server you control, take a look at our VPS hosting options and talk to our team about a sensible failover setup.
Frequently asked questions
What is a cloud zone outage?
It is a failure in one zone, a separate location inside a cloud region, often caused by power, cooling or networking faults. Workloads in that zone can go offline. Whether your site survives depends on whether it also runs somewhere else.
Did the Google Cloud London outage take down every website?
No. Reports linked it to Revolut and several other services, but not every disruption seen on outage trackers was confirmed as connected. CNN, citing Reuters, said it was unclear whether the Google Cloud outage was behind some bank issues.
Do small businesses need multi-region hosting?
Rarely. A tested off-site backup, a standby server in another location and a short DNS TTL cover most realistic risks. Multi-region setups add cost and complexity that only pay off if downtime is very expensive.
Will a VPS protect me from a data centre power failure?
A single VPS sits in one location, so on its own it does not. A second VPS in another location, plus off-site backups and a switch-over plan, does. The failover design matters more than the product name.
How quickly can I fail over to another server?
It depends on preparation: current data on the standby, a low DNS TTL and a written runbook. Rehearse once so you know your real switch-over time instead of guessing.
