Google Cloud London Outage: What the Power Fault Means for UK Banks and Cloud Resilience

What actually happened​

Google's incident dashboard lists the disruption as lasting 7 hours and 52 minutes, from 7:08 a.m. to 3 p.m. British Summer Time on Oct. 20. The trigger was a power event in the europe-west2-b zone in London, with errors and network failures from 06:08 UTC.

Google's own statement to Reuters described a disruption at a third-party facility in its europe-west2 cloud region due to a power event. Reuters describes that region as a London-based network of multiple data centers and availability zones that serves customers across Europe.

The region is not a single building, so why did the effects spread? The reporting suggests the damage went beyond one zone:

• Services in the affected zone became unavailable, while some services elsewhere in the London region saw elevated errors and intermittent network problems.
• Affected products included Compute Engine, Google Kubernetes Engine, Cloud SQL and Cloud Storage.
• A developer write-up counted thirty-eight products listed on the incident.
• Google advised customers to move workloads to another location if they could.

There is one open question. A DEV Community write-up citing Computer Weekly says the site's backup generators failed to engage. That claim is secondhand and I could not verify it against Google's own incident record. The same write-up notes Google has not yet explained why the two healthy zones did not fully absorb the load. Google has promised an analysis on its status dashboard, and that report should settle both points.

Who felt it, and who we can say felt it​

The affected names vary in how well they are confirmed.

• Revolut: Reuters reported that a wide range of services including logging in, card payments and cash withdrawals were affected at a bank with roughly 13 million UK customers. The company said customer funds and data stayed safe.
• Lloyds and HSBC: Both acknowledged customer access problems. Reuters said Lloyds expected a return to normal because the root issues had been resolved.
• Halifax: Halifax also reported problems with online banking and its app.
• Rightmove, DPD, NHS England and Royal Mail: These appeared in Downdetector. Reuters stressed that Downdetector aggregates reports from multiple sources, including users, and actual user impact may vary. Royal Mail said letter and parcel deliveries were unaffected.

Outage-tracker spikes show coinciding problems. They do not prove that every service ran on Google Cloud or that Google caused every symptom. One example is ING Germany, which said it saw no indication that its disruption was due to an external cause.

The concentration argument, with attribution​

New Electronics frames the outage as a warning about reliance on a few hyperscalers. It quotes several industry voices. These are opinions, not independently verified findings.

• Proton's chief operating officer, Raphael Auphan, says Europe is almost entirely dependent on a handful of cloud companies. He argues for more investment in regional providers.
• Jamie Beckland of APIContext argues that banks can outsource infrastructure but not responsibility for resilience.
• Graeme Stewart of Check Point compares the digital economy to millions of organisations plugged into one extension lead.

The argument is persuasive, but it has limits. Diversifying providers does not remove the risk that an organisation's own architecture cannot actually fail over. The evidence here shows a power fault in one zone. It does not show which customer configurations would have survived it. Calling for "multi-cloud" is easy. A tested, working recovery path is much harder to build.

The regulatory backdrop, including Microsoft​

This is where the story reaches Microsoft administrators. On 10 July 2026, HM Treasury announced its first Critical Third Party designations. The Bank of England said these were Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd, and Oracle Corporation UK Limited. Joint oversight by the Bank, the PRA and the FCA began on 13 July.

The regulators' rationale is the scenario that just played out. Because many firms rely on these services, disruption could affect multiple firms or markets at the same time. Designated providers must manage risks to their critical services and keep regulators and customer firms informed during major incidents.

Designation does not move responsibility onto the provider. The Bank says the regime complements, but does not replace, existing outsourcing and operational resilience rules for regulated firms. The European Banking Authority made the same point to Reuters, saying designation does not transfer responsibility for incident management or relieve financial entities of their own obligations.

The regulatory response followed quickly:

• The EBA said it had contacted Google Cloud to understand the incident and assess its effect on EU financial entities.
• The FCA said it was engaging with Google. Under the UK regime, designated providers must report serious outages to the FCA and the Bank.
• Parliament's Treasury Committee wrote to the Bank of England and the FCA asking about the scale of the disruption, the regulators' response and any financial harm.
• Reuters called the outage the first major test of the new European rules on critical technology providers.

The timing is notable. On 8 October, twelve days before the outage, the Bank-backed CMORG group finished SIMEX26, a sector-wide exercise on a global cloud services disruption. It involved the 38 largest and most systemically important banks and market infrastructure operators. The Bank said it expects firms to act on the lessons. The exercise was a scenario, "not informed by any specific threat information", so it was not a response to this event.

What IT and risk teams can do now​

The following is my own analysis based on general industry practice. It is not a checklist from the Bank or Google. The same questions apply whether your cloud is Azure, AWS or Google Cloud.

1. Map dependencies by provider and region. List which business-critical services run where. Include the indirect dependencies, such as a SaaS vendor or payment processor hosted on the same cloud.
2. Check zone versus region. The incident shows that zonal resources, such as VMs and disks pinned to a failed zone, have no automatic workaround. Confirm which of your workloads are truly zone-redundant.
3. Test failover, not just configure it. Verify that data replication, identity, networking, DNS and third-party integrations still work when the primary location is down.
4. Watch for capacity and degraded-mode behaviour. Google prioritised restoring existing workloads during recovery. Do not assume you can spin up replacement capacity in the middle of a regional incident.
5. Use provider health tooling and your own monitoring. Google separates its public status page from Personalized Service Health, which gives per-project incident detail, alerts, API data and logs. Azure and AWS offer similar per-tenant views. Add independent monitoring so you are not relying on the vendor's own dashboard to tell you it is down.
6. Rehearse communications and manual workarounds. Customers blame the brand they know, not the cloud underneath. The outage showed this clearly: Revolut, not Google, was the name on the failed payments.

The takeaway​

Google restored service, but recovery on the provider's side is a different thing from continuity for the customer. Regulators are now building oversight around that gap. The sensible reading is neither "abandon the cloud" nor "buy a second cloud and relax". Know your dependencies, and test your recovery before the next outage does it for you.

Google's promised post-incident analysis should clarify the generator question and why the failure spread beyond one zone. Until it appears, treat the more granular technical claims in circulation with caution.