What happened in the Google Cloud London outage?
At 07:08 UK time, Google Cloud’s service health page logged “elevated errors and intermittent network failures” in europe-west2, its London region. Google later confirmed the cause in a single, unglamorous phrase: “a power event” in one zone, europe-west2-b. It reported the power event as mitigated at 12:12 and said full recovery of existing workloads was tentatively expected by 14:00. The incident listed 38 affected Google Cloud products, including Compute Engine, Cloud SQL and Cloud Storage.
By mid-morning the effects had reached the high street. According to live coverage from Tom’s Guide and TechRadar, Revolut reported disruption to services including card payments, and Halifax said some customers were having problems with its app and online banking. Outage reports also rose for Lloyds, Spotify, Rightmove and DPD, Royal Mail parcel tracking slowed, and some users reported problems with the NHS App.
One zone failed, so why did customers notice?
A cloud region is built in zones precisely so that one of them can fail. Google’s own advice during the incident was that affected customers should move their workloads to another zone or region “if feasible”. That last phrase is doing an awful lot of work.
I do not know how any of the organisations affected are architected, and it would be unfair to guess. Some services across the wider London region also showed errors, so this was not purely a single-zone issue. But when one building loses power and the high street notices, it tells you that, somewhere in the chain, resilience existed on paper rather than in practice.
That chain often includes services bought indirectly. An organisation can depend on a cloud region through a software supplier, a payment platform or its managed service provider without ever holding a contract with the cloud provider itself. Mapping third-party dependencies is how those hidden links come to light before an incident rather than during one.
A year on from the AWS outage
The timing is hard to miss. The outage came exactly one year after the AWS US-EAST-1 outage of 20 October 2025, which disrupted UK banking apps and HMRC services from the other side of the Atlantic. We set out the lessons from that incident at the time, and again after the Cloudflare outage that followed. Twelve months on, the provider has changed and the lesson has not.
What the outage means for financial services firms
There is also a regulatory edge this time. From 13 July 2026, HM Treasury designated Google Cloud EMEA Limited, alongside Amazon Web Services EMEA SARL, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited, as the first critical third parties to the UK financial system. That brings the services they provide to the financial sector under joint oversight from the Bank of England, the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA).
Designation does not shift responsibility away from the banks and insurers that use these services. HM Treasury’s announcement is explicit that financial firms remain responsible for managing risks arising from their third-party suppliers. I would expect this incident to be among the first real tests of the regime, and the regulators to ask financial services firms as many questions as they ask Google.
Four things to do after the Google Cloud outage
The right response to a power cut in a London data hall is not a hasty plan to leave the cloud. The useful steps are more prosaic.
1. Know where your workloads run
Find out which region and which zones your important workloads sit in, and ask the same of your software suppliers and your managed service provider. Identify where a single location or supplier could take out more than one service at once, and who owns the decision to fail over.
2. Test the failover
Owning a failover capability is not the same as being able to use it. An untested recovery plan is a hope with a document number. Run a realistic exercise, record how long recovery took and what got in the way, and include the return to normal running.
3. Set impact tolerances in customer terms
“Four hours without card payments” is a decision a board can make. “99.9% availability” is not. Translate availability targets into what customers and staff would experience, and use that to set recovery priorities. For regulated firms, this should connect to existing work on important business services and impact tolerances.
4. Rehearse the communication
Agree who speaks, through which channels and how updates are approved, bearing in mind that your own website or email may be affected. Your customers will forgive an outage far sooner than they forgive silence about it.
The third point matters most. The customer standing at a till with a declined card does not know what europe-west2-b is, and has no reason to care. Their verdict on the morning will not be issued by a status page.
What this means for your organisation
The question is not really whether the cloud is resilient. In most cases it is far more resilient than the server rooms it replaced. The real question is whether you have bought that resilience, configured it and tested it, or simply assumed it came free with the invoice. On 20 October, a number of organisations found out which.
If the outage has raised questions about your own arrangements, our managed infrastructure and cloud teams can help you map where your services run and test how they recover. Get in touch to talk it through.