Google Cloud's October 2026 London Outage Explained: Why Backup Power Failed

Everything you placed only in that zone stops, and things spread across zones can still slow down. If you searched for a Google Cloud outage Europe-wide on 20 October 2026, the real story is smaller and more useful.

Google's final report says one data centre facility, the one hosting zone europe-west2-b in London, lost power. Customers saw impact for 6 hours and 8 minutes. Google says it found no impact outside the europe-west2 region.

Picture a common setup. A payments app for UK customers runs its web servers on a few virtual machines in europe-west2-b, with one database in the same zone. The setup is made up, but the zone, times and failure are from Google's report. At 07:00 London time (11:30 in India) both stopped answering, and nothing in the app's own code was wrong.

This guide follows that app. You will see why the backup power failed and why the other zones suffered. Then you will see how to build and test the app so that losing a zone hurts less.

You need a handful of cloud words and a handful of power words. Each gets one plain line here.

• Region: a geographic area, such as London, made of several zones. Google lists europe-west2 as London.
• Zone: a deployment area inside a region. Google's docs say zones should be treated as a single failure domain, meaning one thing that can fail as a unit.
• Zonal resource: something that lives in one zone, like a single virtual machine (VM). Regional resource: something Google spreads across zones for you, like a regional instance group.
• Failover: moving work automatically from a failed place to a healthy one.
• Control plane: the part of a cloud that creates, changes and deletes resources, as opposed to the part that serves your traffic. You reach it through an API, the interface programs use to call a service.

• Utility feed: a power line from the electricity company. This site had two, called feed A and feed B.
• Breaker: a heavy-duty switch on a feed. Opened and locked, it lets no power through, even when the utility side is still live.
• UPS (uninterruptible power supply): batteries that carry the load for a short time. Here they lasted 5 minutes.
• PLC (programmable logic controller): a small industrial computer. Here it decided when to start the diesel generators.

No. Google's final report says it did not find any impact outside the europe-west2 region. Inside that region, one zone went down completely and the other two were slowed by the fallout.

Press coverage still made it feel bigger. A PA Media report quoted Revolut as saying it had "a service disruption affecting multiple services". The reporter wrote that the issue was understood to be linked to Google Cloud. Google's report names no customers.

The timeline in Google's own times

Google's report uses US Pacific time, and it adds London times to each entry. The table gives London and India times too, converted with Python's time zone database.

Look at the gap between power and recovery. Standby power was back within an hour, and the data halls had power by 00:20. Storage devices that shut down uncleanly then needed recovery, and traffic was let back in gradually.

Because the PLC thought the site still had a live power feed. Its voltage sensor for feed B sat on the utility side of a breaker that was locked open, so it read voltage that never reached the building.

How the site was set up that night

The facility normally runs on two utility feeds. On 14 October 2026 a quarterly generator load test found issues, and feed B's breaker was opened and locked for repairs. From then on, feed A carried the whole load alone.

At 22:53 Pacific on 19 October, an external underground cable fault on the utility network killed feed A. The UPS batteries took over at once. Google's report says they provide 5 minutes of runtime.

What the controller saw

Google's report says the PLC was programmed to check whether voltage was present on the feeder before commanding a generator start. Its undervoltage sensing for feed B was wired upstream, on the line side, of feed B's breaker.

So the sensor saw healthy voltage on a line that was cut off from the building by the open breaker. The report calls this a misconfiguration of PLC logic that did not check both an undervoltage condition and the physical breaker position. Breaker position is the missing check from the prediction above. The generators stayed off, the batteries drained, and the data halls, the rooms full of servers, lost all power.

Power came back a different way. At 23:54 the team began restoring power from a standby utility source, and data hall power was re-established at 00:20.

An everyday picture: a housing society's water supply

Think of a society that gets water from two municipal lines and has a borewell pump for emergencies. A small controller starts the pump only when it sees no pressure on any municipal line.

Where the picture breaks: a water tank lasts hours, while these batteries lasted 5 minutes by design. A real PLC also reads many signals, and the report's fix is to check breaker position as well as voltage.

Because the work did not disappear; it moved. From 23:09 Pacific, Google's routing and customers' own apps failed over to zones a and c, and that sudden demand saturated them.

The report names two main causes for impact outside zone b. The first is instant demand surges on the neighbouring zones. The second is control-plane dependencies that crossed zone boundaries.

• Demand surge: redirected queries, high-availability database failovers and moved compute work filled the spare compute in the other zones.
• Cross-zone dependencies: some regional control planes called metadata and catalog components in the offline zone. Those calls timed out, so job submissions stalled and API responses slowed.
• Errors: customers saw intermittent HTTP 500 and 503 errors across the region. Both codes mean the server failed or was too busy to answer.
• Lost control: for a while, some regional resources could not be created, updated or deleted.

Back to the payments app. Even if it had kept a copy in zone a, its failover would have joined that rush for capacity. The report says some failovers were unsuccessful due to capacity constraints and difficulty in replicating the underlying storage mechanism.

Regional resources are designed to survive it; zonal resources do not unless you build a copy in another zone. Google's reliability guide says a failure in a zone might affect the zonal resources provisioned in that zone.

The report says the same for VMs. Compute Engine zonal resources need customers to provision failover or cross-zone recovery resources if needed. In other words, a single VM in zone b is your problem to protect.

Read the last column carefully. Regional did not mean untouched. The report says products outside zone b saw degradation and failover issues, driven by sudden compute capacity exhaustion.

One more detail matters for planning. Google's geography page says each region has three or more zones in three or more physical data centres. It names Stockholm, Osaka and Montreal as exceptions, with three zones in one or two data centres, as of 26 October 2026. In those regions, two zones can share a building.

Enough that the zones left can carry the full load by themselves. With three zones that means about 50% extra; with two zones it means double.

Google's regional instance group docs explain why spare capacity must already be running. When a zone fails, the instances in the remaining zones keep serving. No new instances are added and none are redistributed unless you set up autoscaling.

Autoscaling, which adds VMs when load rises, sounds like the answer. But it needs fresh capacity in zones a and c at the exact moment everyone else wants it, and the report shows that capacity ran short. Spare VMs that are already running do not have to win that race.

The script below does the sums. It uses Google's published availability targets and the outage length from the report. It runs on Python 3.13 with no extra packages.

import math

# Targets from Google's "Building blocks of reliability" page
targets = {"single zone": 0.999, "multi-zone": 0.9999, "multi-region": 0.99999}
month_s = 30 * 24 * 60 * 60  # seconds in a 30-day month

for name, t in targets.items():
    down_s = (1 - t) * month_s
    print(f"{name}: {down_s / 60:.1f} min ({down_s:.0f} s) of downtime a month")

outage_min = 6 * 60 + 8  # 23:00 to 05:08 US/Pacific, from Google's report
single_zone_min = (1 - 0.999) * month_s / 60
print(f"outage: {outage_min} min = {outage_min / single_zone_min:.1f} months "
      f"of a single-zone budget")

def vms_to_run(needed, zones):
    per_zone = math.ceil(needed / (zones - 1))  # one zone may vanish
    return per_zone * zones, per_zone

for zones in (2, 3):
    total, per_zone = vms_to_run(20, zones)
    print(f"{zones} zones: run {total} VMs, {per_zone} per zone, "
          f"{total / 20 - 1:.0%} extra")

Running it prints exactly this:

single zone: 43.2 min (2592 s) of downtime a month
multi-zone: 4.3 min (259 s) of downtime a month
multi-region: 0.4 min (26 s) of downtime a month
outage: 368 min = 8.5 months of a single-zone budget
2 zones: run 40 VMs, 20 per zone, 100% extra
3 zones: run 30 VMs, 10 per zone, 50% extra

Two warnings keep this honest. Google's page says these percentages are targets, and service SLAs can differ. The sum also assumes each zone holds an equal share of the VMs.

For the payments app, the fix is now concrete. It needs 20 web VMs at peak, so it runs a regional group of 30 across three zones. Its database moves to Cloud SQL with high availability, which keeps a synchronous standby in another zone and fails over automatically.

Take a zone away on purpose, in a controlled window, and watch whether the rest carries full load. Google's docs include a page on simulating a zone outage for a regional instance group, built for exactly this check.

That page's script stops and starts Apache, a web server, on the VMs by default. You replace those commands with your own failure and recovery. The steps below wrap it in a full drill.

1. 1

   List what lives in each zone

   Mark every VM, disk, database and cluster as zonal or regional. Anything zonal with no copy elsewhere is a single point of failure.

2. 2

   Find hidden cross-zone dependencies

   Ask what your recovery needs: new VMs, deploys or config changes. The report shows creating and changing resources can fail during a zone outage.

3. 3

   Run the zone-outage simulation

   Use the script from Google's simulation page, with your own failure command, to take one zone's instances out. Keep real traffic or a load test running.

4. 4

   Measure against the spare-capacity sum

   Check that latency and the rate of 500 and 503 errors stay within your targets, with one zone gone and no autoscaling help.

5. 5

   Repeat while something is already broken

   Run the drill during planned maintenance too. This outage struck while one power feed was out for repairs.

6. 6

   Practise who says what

   Rehearse the runbook and the customer message. Google's own fixes include an automated alert-to-communication mechanism.

Google fixed the controller first and listed the rest, mostly with estimated dates. The table shows each action's status as written in the final report of 27 October 2026.

Where Google's own documents disagree

Google's status updates of 20 October, the preliminary report of 22 October and the final report of 27 October differ in places. None of these change the lesson, but they matter if you quote numbers.

• Cause: the preliminary report described a power grid disruption and a PLC that failed to start the generators. Only the final report mentions the cable fault and the line-side wiring.
• Times: the preliminary report gives 23:08 for detection and 05:10 for the end. The final report's timeline gives 23:04 and 05:08.
• Looker Studio: status updates on 20 October said Looker Studio was not impacted. Both reports' lists of impacted services include it.

These differences are as of 28 October 2026. Quote the final report, and say which document a number came from.

It is a different incident with a different lesson. On 8 and 9 October, a configuration change to storage load balancing in us-central1 (Iowa) bypassed capacity-aware routing and caused failed writes.

That outage taught you to retry safely. This one teaches you where to place things, because no retry helps when every copy sits in one dark zone. Read them together: retries handle short, partial failures, and multi-zone design handles a whole zone going away.

Tell it as a chain of causes, then turn each link into a design choice.

1. 1

   State the scope

   One zone in Google's London region lost power, and customers saw 6 hours 8 minutes of impact. The rest of the region degraded; Google found no impact outside it.

2. 2

   Name the chain

   One feed was out for repair, the other was cut, and the generator controller sensed voltage on the wrong side of a locked breaker.

3. 3

   Explain the spread

   Failover moved work into the other zones at once, and some regional control planes still depended on the dead zone.

4. 4

   Design for it

   Spread across three zones with 50% spare capacity, use regional or HA versions of stateful services, and do not rely on creating resources mid-outage.

5. 5

   Prove it

   Run a zone-outage drill, including during maintenance, and measure errors and latency with one zone gone.