Google Cloud London Outage Report: Lessons for Banks

Google published its final report on the Google Cloud outage in London on October 27, 2026. Utility power failed, and the backup generators never started because their control logic was misconfigured. The disruption lasted 6 hours and 8 minutes and spilled over into banking and fintech apps across the United Kingdom.

What happened in zone europe-west2-b

Google Cloud groups its infrastructure into regions, each a cluster of data centers in one geographic area. Every region is split into zones, locations with separate power, cooling, and networking. The London region, europe-west2, has three zones: europe-west2-a, -b, and -c.

According to Google’s incident report, the trouble began on Tuesday, October 20, 2026, at 06:53 London time. The utility provider lost power after an underground cable fault on the grid outside the facility that houses zone europe-west2-b.

The facility normally draws power from two utility feeds. At the time, one feed was locked out for repairs, which left the building on a single feed. When that feed failed, the diesel generators should have started automatically and picked up the load. They did not.

The UPS batteries (uninterruptible power supply) carried the servers as designed until their reserves ran out. At 07:00 London time, hosts, network gear, and storage in the zone lost power. Automated monitoring alerted Google engineers four minutes later.

The fault was in the generator control logic

The most useful part of the final report explains why the generators stayed silent. The facility relies on a PLC (programmable logic controller), a small industrial computer that decides when the generators start. The PLC watches for low voltage and orders a generator start when it sees one.

Google says the PLC’s voltage sensors were wired on the line side of the breaker for the feed under repair. That breaker was open, but the cable on its utility side was still live. The PLC therefore read normal voltage and never sent a start signal. Google describes this as a misconfiguration in PLC logic that did not check both the undervoltage condition and the physical position of the breaker.

Faults like this tend to stay hidden in daily operations. While both utility feeds are active, the PLC logic is never exercised against the combination of one feed under repair and the other failing. The gap only appears when maintenance and a fault happen at the same time.

Impact spread to other zones and to banking apps

The physical power loss was confined to europe-west2-b. Google’s report notes, however, that some customers in zones -a and -c, and services spanning the whole region, also saw elevated latency and errors. As traffic moved away from the dead zone, neighboring zones absorbed a sudden surge in load.

The report’s list of affected products runs to dozens of services, from Compute Engine virtual machines to databases and analytics. Outside Google, the effects reached everyday services. AFP, in a report carried by Khaleej Times, said Revolut customers could not withdraw cash at ATMs, make transfers, or top up cards. Revolut did not confirm a link to Google, but a source close to the matter attributed the disruption to the Google Cloud failure. Lloyds and HSBC confirmed that customers had problems with their banking services.

The PA news agency, via The Irish News, reported that the cloud video platform used by HM Courts & Tribunals Service for hearings in England and Wales went down and came back around midday. The budgeting app Emma told users it was offline because of the Google Cloud outage. Google said that day, “We apologise to all who are affected by the disruption.”

Recovery took six hours

Power from the standby utility source returned at 07:54, and the data halls were re-energized at 08:20 London time. The rest of the recovery moved more slowly. Many storage devices had shut down abruptly, so their data integrity had to be verified before customer traffic was let back in.

Google began re-admitting traffic in stages at 11:45. Google Cloud services and APIs were fully available to customers at 12:11, and by 13:08, 99.5 percent of Compute Engine virtual machines were operating normally. A small number of VMs needed longer recovery through support cases.

The report lists a set of corrective actions. They include restoring the dual-feed power configuration, running full generator load transfer tests, reviewing the PLC code, checking similar sites worldwide by November 15, 2026, and freezing planned maintenance at comparable facilities. Google also committed to building automated customer notifications for incidents that affect a single location.

Why it matters for financial services in Indonesia

Banks, fintech companies, and payment providers in Indonesia increasingly run their applications in the cloud. Google Cloud, for example, operates a Jakarta region (asia-southeast2) with three zones, according to its Compute Engine documentation. That is the same structure as the London region.

For banks, the rules already exist. According to Kontan’s summary of Peraturan OJK Nomor 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum (the Financial Services Authority regulation on IT management by commercial banks), banks must place their electronic systems in a data center and a disaster recovery center (DRC) inside Indonesia. Their disaster recovery plans must be tested and reviewed at least once a year.

The London case shows why an annual test alone falls short. Backup systems that look complete on paper can fail when one component is out for maintenance. Google’s own documentation advises customers to spread resources across zones and says that placing them in different regions provides an even higher degree of failure independence.

What this means for banks and fintech companies

The cloud provider is responsible for the building, the power, and the generators. Customers are responsible for how their applications are deployed and recovered. That split puts several steps squarely with bank and fintech IT teams.

1. Map dependencies by zone. Record which services run in only one zone, including databases, message queues, and third-party services such as OTP providers or payment gateways.
2. Test zone failover under real conditions. Shut down a zone in a scheduled drill and measure recovery time. Also test the case where another zone is already in maintenance.
3. Decide on a second region for core services. For transfers, payments, and sign-in, set recovery time targets and decide whether a second region is needed, keeping Indonesia’s data location rules in mind.
4. Prepare customer communications. Have notification templates, a status page, and support channels that do not depend on the same systems. Revolut’s statement that customer money and data were safe is the kind of message that should be ready in advance.

The load surge on neighboring zones also deserves planning. Reserving spare capacity ahead of time helps, because during an incident many customers compete for resources in the same surviving zones. Teams designing this kind of architecture can start with our cloud computing services, which cover multi-zone design and recovery planning.

Frequently asked questions

Did the outage affect Google Cloud’s Jakarta region?

No. Google’s report states that the impact was limited to the europe-west2 region in London and did not affect other regions.

Is running an application across multiple zones enough?

Multiple zones protect against the loss of a single facility, but London showed that neighboring zones can slow down when they absorb the overflow. For services that must stay up, combine multi-zone deployment with reserved spare capacity and a second-region plan.

When did Google publish the full report?

Google released a preliminary report on October 22, 2026, and the final report on October 27, 2026. Some corrective actions are scheduled to finish between late October and November 15, 2026.

Conclusion

The Google Cloud London outage started with one utility cable and one flawed piece of control logic, yet it reached ATMs and courtrooms. For banks and fintech companies, the lesson is to test backups under imperfect conditions. Merakit helps financial services organizations design cloud architectures that are ready for failures like this one. A related case is covered in our analysis of the strikes on Yandex data centers.

Sources

• Google Cloud Service Health: Incident Report, europe-west2 Multi-Service Disruption (final report, October 27, 2026)
• Khaleej Times (AFP): UK power outage hits Google Cloud services, disrupts Revolut banking (October 20, 2026)
• The Irish News (PA): Banks and courts affected by disruption as Google apologises for cloud outage (October 20, 2026)
• ABC News: European banks, websites hit as Google Cloud data centre goes offline for hours (October 20, 2026)
• Google Cloud: Regions and zones, Compute Engine documentation (accessed October 28, 2026)
• Kontan: Ini 11 pokok pengaturan POJK penyelenggaraan teknologi informasi di bank umum (August 4, 2022)