Cut-paper illustration of three cloud availability zones in a row; the middle zone is dark with a lightning bolt and an unplugged power cable, while the two outer zones stay lit, and a small bank building and a mobile phone below carry warning signs

On Tuesday, October 20, one zone of Google Cloud's London region went dark at 7:08 in the morning, British time, for 7 hours and 52 minutes. By mid-morning, banking apps would not load, card payments failed at tills, and cash withdrawals were unreliable. Google's status page attributed it to a power event in a single zone: europe-west2-b.

That is the whole story and none of the useful work. The useful work is the diagnosis. When users report that everything is broken at once, "the cloud is down" feels like an answer. It is a guess, and guesses are how a team fixes the wrong layer, replays work that already completed, or declares recovery too early. London is a good case to practise on: one zone failed, the region wobbled, and the damage showed up several layers from the data centre.

Do not start with "Google is down"

Start with what users saw, in their words, with times. "The app will not load" and "payments fail but the website works" point at different layers. Write the symptoms down before you open the status page, which will happily confirm whatever you already believe.

Then check three things separately: your telemetry, the provider status page, and your dependencies, including ones you did not choose directly. Clean telemetry plus a red status page means a monitoring gap or a forgotten dependency. Red telemetry plus a green status page means the problem is probably yours. Either way, you have evidence instead of a slogan.

Read the status page for what it actually says

Google's incident record is precise in a way headlines are not. Services in europe-west2-b became unavailable, some services elsewhere in the region saw elevated errors, recovery prioritised existing workloads, and new workload creation was limited for a time. Later, Google confirmed full service availability.

Three distinctions in that record matter. Zone is not region: London's europe-west2 region has three availability zones, the power event hit one, yet the other two did not absorb everything cleanly. If your plan says "multi-zone" and stops there, this incident is the counterexample to file away. Unavailable is not the same as degraded: a service down in one zone calls for failover or waiting, while elevated errors across a region call for expecting flakiness everywhere and not restarting things in a panic. And restored is not the same as recovered: Google restoring service is the start of your recovery, not the end of it. Your queues, scheduled jobs, and half-finished transactions still need checking.

Trace the chain before you touch anything

The outage reached people who never think about Google Cloud. Revolut reported disrupted card payments and ATM withdrawals, while assuring customers their money and data were safe. Halifax reported problems with online banking and its app. These are customers of services built on top of services built on top of a region. That layering is why one failed zone can look like a banking outage.

Run this check first:

What users report First check What it tells you
App will not load at all Front end and load balancer health, then the status page Whether the failure is at your door or the platform's
Sign-ins fail Identity provider status, plus DNS Whether authentication is a separate dependency with its own outage
Reads work, writes fail Database service and its zone placement Whether one zone holds the writable copy
Payments fail, everything else works Payment provider's status Whether the break is downstream of you entirely
Intermittent errors everywhere Error rates by zone and service, over time Whether you are seeing regional degradation, not a clean failure

Each row ends in a check, not an action. Restarting, failing over, and replaying are reasonable in the right situation and harmful in the wrong one. In June 2025, a Google Cloud disruption reached GitHub, Mailchimp, and Twitch: the services people noticed were not the ones that failed, but the ones standing on top.

Multi-zone is not multi-region

The durable lesson from London applies to every provider. Ask four questions about anything you run in a single region, and write the answers where the on-call person can find them at 7 in the morning. Which zone holds the writable database, and what happens to writes if that zone goes away? Which services are regional rather than zonal, and do they fail over on their own? If you fail over, does the target have capacity, or does it share the same congested control plane? And when did you last test the failover, rather than last review the diagram of it?

London gave every team a free failure scenario to test against: one zone dark, the rest of the region flaky, new workload creation limited. If your plan assumes fresh capacity in the middle of that, it assumes the one thing the incident record says was constrained.

Not every workload needs two regions. That is expensive, and often the wrong call. The decision should be deliberate: this workload stays in one region because the business accepts the risk, and here is the recovery time measured. "We are in the cloud, so we are resilient" is a hope with a monthly bill, not a decision.

Recovery is a checklist, not a moment

When the provider says service is restored, run the recovery checks before you tell anyone the incident is over:

  1. Test the functions people use: sign-ins, transactions, and connections to other services. Not just the homepage.
  2. Review failed jobs, queues, and scheduled tasks, and decide explicitly what gets replayed and what gets dropped.
  3. Before replaying anything, check whether it completed without returning a confirmation. Retrying a payment that already went through creates a second problem that looks like a first problem.
  4. Ask suppliers to confirm recovery and name outstanding delays. Your recovery statement is only as good as theirs.
  5. Compare your timeline with Google's published analysis when it appears; it should settle what failed first.

Step 3 is the one teams skip under pressure, and it creates the follow-up incident. A queue of retries proves work was interrupted, not lost. Treat it as unknown until checked.

Regulators moved quickly after this one. The European Banking Authority asked Google for more information and the UK Financial Conduct Authority confirmed it was engaging with the company. Google was already in scope of the UK and EU oversight frameworks for critical technology providers. You do not need to be a bank to take the useful part of that: while the provider's analysis is being written, write your own timeline. When did users first report problems, what did the status page say at each point, what did you change, and when was your service usable again? Keep it factual and short. It turns an outage into a decision at the next planning meeting, instead of a story that gets vaguer every time it is retold.

The power event lasted less than eight hours. The slower questions remain: where does your app run, what does it stand on, and what will you check before you declare it back? The answers do not depend on which provider had the bad morning. They depend on whether anyone wrote them down beforehand.

Sources