Back

One Google Cloud Zone in London Lost Power for Nearly Eight Hours. Do You Know Where Your Site Lives?

A power event in one London data center zone stopped Revolut card payments and disrupted dozens of Google Cloud products. Here's what failed, what didn't, and what to check on your own sites.

Jagdish Patil

•

Oct 20, 2026

What happened on October 20

Google's status page said the trouble began at 06:08 UTC on October 20 (Google posts its times in US Pacific, so you'll see it written differently there). The first notices said multiple services in the London region, europe-west2, were having issues. The later wording was blunter: elevated errors and intermittent network failures.

Time (UTC)	What Google said or did
06:08	Incident begins, with multiple services in the London region affected
11:12	Google posts that a power event caused an outage within the europe-west2-b zone, and that the event is mitigated
11:58	Existing workloads are being recovered first, and customers may not yet be able to create new ones
14:00	End time listed in Google's incident record, as reported by FourWeekMBA

Interesting Engineering put the total at nearly eight hours before Google marked the incident closed. TechRadar's live blog, which quoted Google's updates as they landed, listed BigQuery, App Engine, Looker and Cloud SQL among the affected services. One tally counts 38 products. Google's advice to affected customers was to move workloads to another zone or region if they could.

Google hasn't said why the power event happened. It says a full investigation is coming, and the findings will be published.

One zone down, a whole region wobbling

The London region has three zones, and they're built to fail separately. If your app runs across all three, losing one should be a bad hour rather than a bad day. Google's own wording on the day was less comforting. Services were unavailable in zone b, and some services across the whole region could see elevated errors and intermittent network trouble.

London has form here. In December 2020, a problem in europe-west2-a left roughly 60 percent of VMs in that zone unreachable from outside it. In July 2022, a cooling failure hit zone a again, and Google later admitted that at the start of the incident it had mistakenly shifted internal traffic away from all three zones instead of only the broken one. In August 2024, a loss of power to networking equipment cut connectivity in the region for 40 minutes.

None of this says Google is unusually fragile. Every large provider has a chapter like this. The point is narrower: "a zone fails on its own" is a design goal, and a design goal isn't a guarantee.

The failover trap hiding in Google's 11:58 update

Look again at the 11:58 UTC update. Existing workloads came back first. New workloads, for a while, could not be created.

Plenty of recovery plans start with "launch replacement servers in a healthy zone." That plan waits on the one thing Google said wasn't available yet. If your failover needs new capacity at the moment of failure, you're in a queue with every other customer who has the same plan.

NordVPN's CTO made a related point to TechRadar: a backup only helps if it doesn't depend on whatever just failed, and a business should check whether its main service and its fallback share the same underlying systems. Copies of your data alone don't keep customers paying or logging in.

Who was hit, and who we can actually say was hit

Here's what holds up. A person familiar with the matter told Reuters that Revolut's outage was related to the Google Cloud disruption. Revolut said card payments, card top ups, ATM withdrawals and currency exchange were partially unavailable.

Here's what doesn't hold up yet. Downdetector showed spikes for Lloyds, HSBC, Barclays, Rightmove, DPD, Royal Mail and others on the same morning. CNN noted it wasn't clear that Google Cloud was behind those, and Business Insider said not every company on its list had named Google Cloud as the cause. Treat the long list as reports, not a confirmed roster.

One name on Business Insider's list deserves a second look if you build sites for clients. Web host SiteGround was on it. The shared hosting plan underneath a client's site often sits on someone else's cloud, and you may not know whose.

Waiting for the status page is its own risk

Google's explanation went up at 11:12 UTC, more than five hours after the 06:08 start. For much of that stretch the status page said the team was investigating.

It's not a one off. When Google's Frankfurt region lost a zone to a power and cooling failure in October 2024, The Register reported that Google first notified users 26 minutes after the incident began and offered no workaround until almost three hours in. Providers tell you what broke once they've worked out what broke. Your own monitor sees a failed page load right away.

That gap decides who calls whom. Hear about it from your monitor and you phone the client first. Hear about it from the status page and the client phones you.

Set it up so you hear first

SIOPS is built for exactly this: the alarm is a native system alarm on the same channel as your morning alarm clock, so silent mode and Do Not Disturb don't swallow it. Here's how we'd set it up for a handful of client sites.

Create one monitor per client URL, not one for the whole account. A zone failure usually takes out some clients and spares others, depending on who hosts where. Give each client its own alarm tone, and the sound tells you whose site failed before you've unlocked the phone. One tap on the lock screen acknowledges the alarm, and then you decide what to do.

Put the host and region in the monitor name, something like "Client name, host, London". When the alarm goes off in the middle of an incident like this one, you'll see at a glance which clients share a failure point.

Then ask each client's host a boring question: which zones does this run in? If the answer is one, you've found your next conversation.

On limits, Hobby is free and covers 5 sites with 1 alarm and a 5 minute polling interval. Serious is $3.75 a month per project when billed monthly (the yearly toggle shows a 20 percent saving). It covers 10 sites, unlimited alarms and a 60 second polling interval, which is where a separate tone for every client makes sense. Each monitored site also gets a public status page on a siops.app subdomain that updates itself, so clients can check for themselves while you work on the fix.

You can start on the free plan at siops.app.