How to Prepare for a Cloud Outage: What One Zone in London Teaches Self-Hosters

On 20 October 2026, Google Cloud's London region, europe-west2, had a service disruption that Google's own status page puts down to a power event inside one availability zone, europe-west2-b. While it lasted, UK banking apps had cards declined and payments fail, and the Guardian reports that courts were hit as well. Google's suggested workaround was to move affected workloads to another zone or region.

The big outlets are covering the news live, so I am not going to recap it. What interests me is the part that applies to anyone running their own servers. A failure inside one building spread into dozens of managed services, and through them into businesses that thought they had bought resilience. The same question, "how far does my blast radius reach?", is one you can answer about your own stack this afternoon.

A checklist: how to prepare for a cloud outage

This is the order I would work in. Each step is small.

1. Write down your dependency list before you need it

Open a text file and list every outside thing your stack needs to work. For most self-hosters that is:

DNS: who answers for your domain, and who holds the registrar login.
The VPS provider: the company, the region, and the account that pays for it.
Object storage: where your backups and media files live.
The mail relay: whatever sends your password resets and alerts.
Any AI API: if a feature calls a hosted model, that is a dependency too.
The one dashboard you use to notice: your uptime checker, your monitoring, your alert channel.

That last line matters more than it looks. Most outages are discovered through something that is also hosted somewhere. If your uptime monitor runs on the same provider as your server, or your alerts go out through a relay on the same network, the thing meant to warn you can go down with the thing it watches.

Write next to each item where it is hosted. If two lines name the same company, you have found a shared failure.

2. Make your backups leave the failure domain

A snapshot on the same provider is convenient, but it is not a backup against that provider. It shares the provider's outage, the provider's billing problem and the provider's account lockout.

"Off" has to mean something concrete:

Another provider: a different company, not just a different region of the same one.
Another account: so one billing or lockout problem cannot reach both.
Different credentials: the key on your server should be able to write new backups, and ideally not delete old ones. If something bad gets onto the server, it should not get your history too.

On my own box I take nightly database dumps and copy them off that provider to object storage somewhere else. It is not clever, but the copy that matters lives outside the place most likely to fail.

3. Test the restore, not the backup

A file existing proves very little. Dumps get cut short, cron jobs fail quietly, and a backup script can happily upload an empty file every night for months. A backup nobody has restored is a hope.

The check I trust looks like this:

Decompress the dump. For a gzip file, gunzip -t backup.sql.gz tells you whether the archive is even readable.
Open the database. Restore it into a throwaway location, never over the live one. For PostgreSQL that means a scratch database loaded with psql or pg_restore. For SQLite it is a copy of the file.
Run an integrity check. For SQLite, PRAGMA integrity_check; should return ok. For other engines, use their own check tools, and at the very least confirm the restore finished without errors.
Confirm the tables you actually need are present. List them, and count rows in the two or three that hold the data you would hate to lose: users, posts, invoices, whatever it is for you.

My restore drill runs a real integrity check on every database rather than trusting that a file exists. If you automate only one thing from this article, make it this.

4. Separate DNS from compute

If your DNS provider and your server are the same company, one incident can take the site and your ability to point it somewhere else at the same time. You cannot move to a new server if you cannot log in to change the record that sends people there.

Keep DNS with a different company from your hosting. Keep your registrar login, and its two-factor recovery codes, somewhere you can reach from a phone. The same thinking runs through my vendor lock-in exit plan.

5. Write a runbook with the steps you will actually take

Not a forty-page document. Two or three steps, written for the version of you who is tired and reading on a phone. Something like:

Check the provider's status page to confirm the problem is them, not you.
If it looks like a long one, start a new server elsewhere and restore last night's dump from off-site storage.
Change the DNS record to point at the new server.

Next to it, write down a source of truth that is not your own server: the provider's status page, bookmarked on your phone and readable over mobile data. If your only way to find out what is happening is a dashboard on the box that is down, you will spend the start of the outage guessing.

6. Accept the honest limit

You cannot fail over a single VPS. There is no second zone and no standby, and a self-hoster should not pretend otherwise.

What you can do is shorten the recovery and keep the data. Downtime ends. Lost data does not come back. If your dumps are off-site and tested, a bad day becomes a rebuild instead of a permanent loss. My setup is a smaller blast radius than a bank's, not a zero one.

What the London incident actually shows

Here is what Google itself has said, and only that. Its status page (incident Xs2XTHzAVC9YnafnPyzj, which I read around 13:45 UTC on 20 October) said: "Multiple services are experiencing issues in the europe-west2 region". It gave the start as "Monday, 2026-10-19 23:08 PDT", which is 06:08 UTC on 20 October.

On the cause, Google wrote: "A power event caused an outage within europe-west2-b zone. The power event is mitigated." It added that "Google Cloud services are unavailable in europe-west2-b zone; some services in europe-west2 region may experience elevated errors and intermittent network issues", that "Customers may not be able to yet create new workloads", and that "Full recovery of existing workloads should be completed, tentatively by Tuesday, 2026-10-20 06:00" PDT.

The same page listed 38 affected Google Cloud products. Among them were Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud SQL, Cloud Storage, BigQuery, Pub/Sub, Memorystore, Persistent Disk, Cloud Load Balancing and Virtual Private Cloud.

The effects showed up a long way from the data centre:

The Telegraph reported bank cards declined at tills and named Revolut, Lloyds, HSBC, Halifax and Barclays among those affected.
The Guardian reported the outage "caused widespread disruption, hitting courts and leaving millions of customers unable to access and send cash at banks including Lloyds, HSBC".
CNN reported multiple Google Cloud services disrupted in the company's London region while Revolut reported a service issue.
Neowin reported HSBC, Revolut, Bank of Scotland, Lloyds, Royal Mail, DPD and Equifax among those affected, and said Revolut had confirmed sign-ups, sign-ins, payments, transfers, top-ups, ATM withdrawals, stock trades and crypto were all down.

Then the workaround. Google wrote: "If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region)." That is reasonable advice. It is also written for customers who already have a second zone ready to take the load. Moving a workload in the middle of an outage is hard unless the second location was built and tested beforehand, and whether it was is exactly the thing an outage tests.

What is not known matters just as much. Google has published no incident report yet, and its status page had not closed the incident when I wrote this. The cause is described only as a power event inside one zone. There is no independent count of how many businesses were affected. Nobody has said whether any customer data was lost. I will not guess at any of them.

The self-hoster's version of the same question

None of this means self-hosting would have saved a bank. That is not the point.

The point is where failure concentrates. Managed services concentrate one provider's failure into many of your dependencies at once. Your database, queue, cache, storage and network can be separate products on separate bills and still sit in the same zone. On a bad day they fail together. Google's list of 38 products is what that looks like from the provider's side.

Self-hosting concentrates your own failures into one place. My single VPS is one machine with one provider. If it goes, everything on it goes. The difference is that I can see the whole blast radius on one screen, and the recovery is mine to run.

Both are blast radii. Neither is zero. The trade is plain: you take on the pager and the patching, and in exchange you own the recovery. You decide where the backups live, and you know what a restore takes because you have done one.

That trade is not right for everyone. But for a personal stack or a small business, a recovery you have practised is often worth more than redundancy you have never seen work.

The lesson

Resilience is not having a second region on a slide. It is knowing which single thing takes you down, and having the data somewhere that outage cannot reach.

So this afternoon: write the dependency list, check where your backups really live, restore one, and move DNS if it shares a company with your server. All of it is easier before the bad day than during it.

If you would like help doing this on your own stack, from the dependency list to a restore drill that actually checks the data, see my services.

Fiverr: hiteshsaini459 · Upwork: hiteshsaini25