One London Zone Lost Power and UK Apps Went Down With It
October 23, 2026 · 7 min read
The Decode, Google Cloud, Reliability, Distributed Systems, Outages, App Development
Welcome to The Decode, now weekly. If this is your first email since June: the plan was a near-daily column, it stalled, and weekly is the fix. Every Friday you'll get one story explained properly, a few quick hits, and the sources behind them. I've also written up the weeks you missed; every issue is at /decode.
This week's lead started at 7 a.m. London time on Tuesday, when a lot of people in the UK opened their banking app and it didn't work.
What happened
At 23:08 Pacific on Monday, October 19 (06:08 UTC, 07:08 in London), Google Cloud services in europe-west2, its London region, started failing. Google's status page eventually listed close to 40 products under one incident: Compute Engine, Persistent Disk, Google Kubernetes Engine, Cloud SQL, Cloud Run, Cloud Storage, Spanner, Firestore, Pub/Sub, BigQuery, the load balancers and VPC networking, and more.
For the first few hours the updates said only that engineers were investigating, with one piece of advice: if feasible, move workloads to another location. Then came the cause, in one sentence:
"A power event caused an outage within europe-west2-b zone."
Google said the power event was mitigated and recovery was underway, with existing workloads prioritised and a warning that customers "may not be able to yet create new workloads." By about 05:10 Pacific most workloads had recovered. The final update, a little after 07:00 Pacific, called it mitigated for most customers, with "a very small number" still affected, and said Google will publish an analysis once its internal investigation is done.
Downstream, The Register reports that customers of Lloyds, HSBC and Revolut were among those hit, along with Royal Mail, Rightmove, DPD, BT and Screwfix. Those are press reports, not statements from each company.
What we don't know yet, as I write this: why the power event happened, why backup power didn't carry the zone, and why services outside that one zone saw errors. As of Tuesday evening there's no preliminary incident report on the status page. Everything below is how I read the public information so far, not the final story.
Zone vs region, in plain terms
Cloud regions are split into zones. Google describes a zone as "a deployment area within a region" and says it designs zones "to minimize the risk of correlated failures caused by physical infrastructure outages like power, cooling, or networking." Power is the first thing on that list.
Google's own reliability guide sorts resources into three kinds:
| Kind | Where it lives | Survives |
|---|---|---|
| Zonal | one zone | nothing beyond that zone |
| Regional | spread across zones in a region | a single zone failing |
| Multi-region | spread across regions | a region failing |
A single VM, a single-zone database, a zonal disk and a zonal Kubernetes cluster are all zonal. If they were in europe-west2-b, they went down with it. That part is expected, and it's why the advice has always been "spread across zones".
The more interesting part is the blast radius. One zone lost power, but Google's own wording moved from that zone to "multiple services" in "the europe-west2 region", and the list includes services that are regional by design, like Spanner, Firestore and Cloud Run. Those are supposed to ride through one zone going away. Either some of their capacity or control plane leaned on that zone, or the recovery itself (everyone failing over and restarting at once) caused the wider errors. I don't know which. That's the question I most want the incident report to answer.
There's also a quieter lesson in "may not be able to yet create new workloads." A lot of failover plans assume you can spin up replacements in the healthy zones. If everyone in the region is doing that at the same moment, and the APIs to create things are degraded, a plan that depends on creating new capacity during the outage is weaker than one that already has capacity running.
What I'm checking in my own backends
I build iOS, Android and Mac apps solo, and my backends are small. That's exactly the setup where "it's in the cloud, it's fine" is easy to believe. Here's my checklist after this week:
- Which region, and which zone? Open the console and look. If a database or VM says
-b(or any single zone), that's a single point of failure, however managed the service feels. - Is the database zonal? Managed databases usually offer a high-availability setting with a standby in another zone. It costs more. Know whether you turned it on.
- What does the app do when the backend is gone? For a mobile app this is the part I control. Does it show cached data and a clear "can't reach the server" state, or does it spin forever, or crash? Do retries back off, or does every phone hammer the API the moment it comes back?
- Hidden regional dependencies. Auth, push, payments, analytics and file storage might live in a region you never chose. A status page for each one is worth bookmarking.
- Can I fail over without creating anything? If the plan is "deploy to another region when it breaks", that step needs the cloud's control plane to work during an incident. Pre-provisioned beats just-in-time.
None of this says the cloud is unreliable. Single-site data centres lose power too. It says the provider gives you the building blocks for surviving a zone or a region, and choosing them is still our job.
Quick hits
- Agent coding tools are converging on the same features (Oct 8–19). Kiro IDE 1.4 (Oct 19) brings Memory to every user, keeping context like repo conventions and ruled-out approaches between sessions. Claude Code's recent releases keep building out background sessions and workflow subagents, and the Codex app keeps refining managed git worktrees, now reaching the ChatGPT iOS app. Memory, background agents and isolated worktrees are becoming the standard kit, whichever tool you pick.
- Banks are locking outside AI agents out of accounts (Oct 13–19). JPMorgan's Jamie Dimon said on the bank's earnings call that it won't let "just any outside agent" inside, citing "rogue agents." Per the FT's reporting, Citi doesn't let third-party agents log in or transact, Bank of America is limiting agent access, and Schwab says it's blocking unauthorised agents, including Meta's Muse. Open-banking style data sharing is still supported; agents logging in with your password is not.
- Apple has an event on Oct 28 (invite sent Oct 19). Apple sent invites for "Pro and Tell" in Los Angeles. What's on the table is still rumour: Bloomberg's Mark Gurman reports OLED, touchscreen MacBook Pros on M5 Pro and M5 Max, plus M6 Macs and an OLED iPad mini. Treat the lineup as unconfirmed until Apple shows it.
- GitHub Universe is Oct 28–29. It's at Fort Mason in San Francisco, with a free virtual pass for the keynotes and sessions. Expect agents to be the theme.
What I'm watching
Google's preliminary incident report for europe-west2, and specifically whether it explains why regional services saw errors when only one zone lost power.
Sources
Google Cloud europe-west2 outage
- Google Cloud Service Health, incident page: multiple services in europe-west2 (Oct 20, 2026)
- Google Cloud docs, Regions and zones
- Google Cloud Architecture Center, Building blocks of reliability
- The Register, Google Cloud says a "power event" caused today's outage (Oct 20, 2026)
Quick hits
- Kiro changelog, Kiro IDE 1.4, memory across chat sessions (Oct 19, 2026)
- Claude Code docs, changelog
- OpenAI, ChatGPT and Codex changelog
- Fortune, Jamie Dimon bars outside AI agents from JPMorgan accounts (Oct 15, 2026)
- Retail Banker International via Yahoo Finance, US banks limit AI agents' access to customer accounts (Oct 19, 2026)
- 9to5Mac, Apple announces special event for October 28 (Oct 19, 2026)
- GitHub, GitHub Universe 2026
STAY UPDATED
Get new posts on software engineering and AI in your inbox. No spam, unsubscribe anytime.