One cloud zone went dark in London. Would your app have stayed up?

One London zone went dark at breakfast

On Tuesday morning, people trying to join court hearings in England and Wales by video got an internal server error. The Criminal Bar Association said barristers "can not proceed with trials and other hearings." Revolut customers had trouble too, and the bank said "all our customers' money and data are safe." Emma, a budgeting app, said it was down "due to a Google Cloud outage." Halifax told a customer on X, "If you need to you can still call us."

Not all of them have said what caused it. The courts service said only that it was working "with our technology partners," and the Press Association, quoted by the Guardian, reported the video outage was believed to be linked to Google. Downdetector showed reports for Lloyds, HSBC, Royal Mail, DPD and others, but as the BBC pointed out, it isn't known whether every company on that list uses Google Cloud.

Here's what Google itself has said on its status page. Trouble in europe-west2, its London region, began at 23:08 Pacific time on Monday, just after 7 a.m. in London. For hours the page described elevated errors and network failures across the region. The workaround it added mid-morning was this: "If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region)." Then, at 04:12 Pacific, it named the cause: "Due to a power event we had suffered an outage within europe-west2-b zone." Google says the power problem is fixed and services are coming back in stages. The incident lists 38 affected products, from Compute Engine and Cloud SQL to Cloud Storage.

Google's latest update, at 04:58 Pacific, said services were recovering, with existing workloads first, and that full recovery of those should be complete, tentatively, by 06:00 Pacific. It also warned that customers "may not be able to yet create new workloads." The incident was still open when we checked just after 8 a.m. Eastern.

London has three of these zones, The Register notes, and they exist so that one can fail without taking the others with it. So as far as Google has said, this wasn't a whole region falling over. It was one zone, plus errors in some regional services. A Reddit commenter quoted by The Register summed up the usual story: "oh man the classic one zone takes a nap and your non-HA service is in it." That's the useful lesson for everyone else, wherever you host.

Work out which pile you're in

Mornings like this sort everyone who runs something online into three piles. Be honest about which one is yours.

Pile one: your own app runs in the zone that went dark. Your servers, database or storage sit in Google's London region, and some of it was in europe-west2-b. You're either still recovering or you've just finished.

Pile two: you don't host there, but something you depend on does. Your site loads, and then checkout, sign-in, delivery tracking, bookings or a video link don't, because the company behind that piece was in London. You may not have known that until today.

Pile three: nothing happened to you. Another provider, another region, or luck. You have the most to gain, because you get to answer these questions while nobody is waiting on you.

Plenty of people will find they can't say which pile they're in. If that's you, you've found this week's job. Ask whoever built or runs your app three things: where does it run, in how many zones, and which outside services does it need before someone can sign in or pay? Then write the answers down somewhere other people can find them.

Your own app is in London

In pile one, first work out which of your parts are tied to a single zone. On Google Cloud, a single virtual machine lives in one zone, and so does an ordinary disk; Google's docs say a zonal disk can only be attached to a machine "in the same zone." A Cloud SQL database set up without high availability is one machine in one zone too, and Google is blunt about what that means: "Cloud SQL doesn't recover standalone instances from a zonal outage automatically." The versions built to outlast a zone (a database with a standby in a second zone, a disk copied across two zones, a cluster spread over several) cost more and take more setting up (Google prices a high-availability Cloud SQL instance at twice a standalone one), which is why plenty of apps don't have them.

Now read Google's workaround again, slowly. Moving a workload to another zone sounds like a button. It's really three questions. Can you rebuild your servers from a script or a saved image, without the one person who set them up? Does a recent copy of your data exist outside the zone that's down? And does anyone know what order to bring things back in? If the only copy of your database is on a disk in europe-west2-b, there's nothing to move until the zone comes back. And Google's own recovery update warned that creating new workloads might not work yet, so a plan that starts with spinning up fresh servers nearby may have to wait too. We've written about keeping a backup your provider can't reach. Today's question is narrower: which parts sit in one zone, and what happens when that zone goes.

Two London wrinkles. The BBC describes europe-west2 as Google's only UK cloud region, so another region means another country. If you've promised customers or a contract that data stays in the UK, decide what you'd do in a calm week, not mid-outage. And more zones aren't a force field: Google also reported errors in some regional services. Spreading out would likely have kept many apps up through the part that went dark, without promising anyone a clean morning.

Meanwhile, tell people something useful. The best statements this morning answered what people were worried about. Revolut led with money and data being safe. Emma said "This is a technical outage, not a security issue." Halifax pointed people to the phone. A good outage message says what still works and what someone can do right now, which is the same test we'd apply to a status label on a public portal. Put it somewhere that doesn't run on the thing that's down.

A vendor you depend on is in London

Pile two is where most businesses actually are. You can't move someone else's workload, but you can decide what your app does when their piece stops answering. Go through each outside service your app calls:

• Does the page wait forever? A checkout that spins for two minutes is worse than one that says, quickly, that something's wrong and what to do instead. Use short timeouts on outside calls and a real message when they trip.
• Is there another way to finish the job? For a store, maybe a second payment provider, or taking the order and emailing a payment link later. For anything like a hearing or a consultation by video, a dial-in number and a clear rule for when to stop waiting and reschedule, with someone named to tell people.
• Will the work wait safely? If orders, forms or messages can sit in a queue and go through when the vendor returns, make sure each one goes through once, not twice.
• Who tells customers? When a vendor's outage becomes yours, your customers hear about it from you. Agree in advance who writes that message. It's the same question as who owns an incident after launch.

Then ask each vendor, in writing:

Where do you run the service we use: which provider, which region, and in how many zones? Were you affected on October 20, 2026, and what did your customers see? What happens on your side when one zone goes down, and when did you last test it? How will you tell us, and how quickly?

A vendor that answers plainly has given you something to plan with. One that sends you a page about resilience has answered too.

Nothing broke for you this time

Pile three gets the easy version: an hour this week, while nobody is waiting.

List everything that holds data. Databases, uploaded files, queues, caches, the search index. Next to each, write where it lives: one zone, several zones, or a whole region. If nobody knows, that's your first finding.

Ask what happens if that zone goes at 7 a.m. How long until customers can use the thing again, and who does the work? Waiting for the provider is a fair answer for some systems, as long as somebody chose it.

Find out whether failover has ever been tried. Plenty of teams set up a standby, tick the box and never use it. A standby you've never failed over to is a hope with a config file. Google's own Cloud SQL docs suggest you "manually initiate failover" to see how your applications are affected, so pick a quiet morning, do it, and time it.

Hear about it from your own checks first. On Tuesday, Google's first status post went up about two and a half hours after the start time it gives. A simple outside check on your sign-in and checkout pages will usually tell you sooner.

Write the customer message now. What still works, what doesn't, what to do instead, and when you'll update. It's quick to write on a calm day.

Send the vendor questions. The ones above, to every service you can't take an order or sign someone in without.

Put this into practice

Before the end of the week:

• Sort yourself into a pile. If you can't, ask the three questions that will.
• Mark every part of your app that holds data as one zone, several zones or a region.
• Try one failover on purpose, with a clock running.
• Write the customer message and decide who sends it.
• Ask your most important vendors where they run.

If your web app turns out to live in one zone, or nobody can say where it lives, that's the kind of work our web application practice does: building the recovery paths, admin controls and explanations people need when the happy path ends. For stores, the same questions apply to checkout and the order flow behind it (ecommerce). For public services, they apply to portals and the appointments behind them (government and public sector). If this morning made you realize you don't know where your app runs, tell us what it does today.

Related work: Spin:Market.