
Yes, Google Cloud went down in London. A major Google Cloud outage hit the europe-west2 region on 20 October 2026, starting at 06:08 UTC (07:08 UK time).
The GCP outage took down Revolut’s app and cards, and disrupted Lloyds, HSBC and other UK businesses. At 11:36 UTC, Google traced the outage to a power event in zone europe-west2-b and said it had been mitigated.
This guide covers what failed, why one London zone caused so much damage and what UK regulators expect. It also gives CTOs five practical steps to protect their cloud infrastructure before the next outage. The GCP outage tracker at the end is updated after every new incident.
GCP Outage in 60 Seconds: What Happened and What to Do
- What failed: Multiple Google Cloud services in the London region (europe-west2), traced to one zone, europe-west2-b.
- Who was hit: Revolut, Lloyds, HSBC, Bank of Scotland, Royal Mail and Screwfix.
- The link: A source told Reuters the Revolut outage was related to the Google Cloud disruption. Google later traced the outage to a power event in one London zone.
- The real risk: Single-zone resources and shared dependencies can turn one zone’s failure into a full outage.
- The regulatory angle: UK financial firms must stay within impact tolerances, even when their cloud provider fails.
- What to do now: Map single-zone resources, test failover and move payments and login to a second region.
Google Cloud London Outage Timeline: 20 October 2026
| Time (UTC) | Time (UK) | What happened |
| 06:08 | 07:08 | Google reports errors and intermittent network failures across multiple services in europe-west2 (London), traced to zone europe-west2-b |
| Around 07:00 | Around 08:00 | Revolut reports on Downdetector spike, peaking at almost 1,500 |
| Morning | Morning | Revolut confirms on X that a service disruption is affecting multiple features |
| Morning | Morning | Lloyds logs around 500 reports, mostly about logging in |
| 10:34 | 11:34 | Google still has no recovery estimate and no workarounds |
| 11:36 | 12:36 | Google traces the outage to a power event in europe-west2-b, says it is mitigated and expects partial recovery within 30 minutes |
Which Google Cloud Services Went Down in London?
Affected Google Cloud Services and What They Break
Google confirmed problems across seven services in europe-west2. Together, they span every layer of a typical application stack.
| Layer | Affected services | What it means for your stack |
| Compute | Cloud Run, Google App Engine | Apps and APIs stop responding |
| Containers | Google Kubernetes Engine (GKE) | Clusters may fail to run or scale workloads |
| Storage | Cloud Filestore, Google Cloud NetApp Volumes | Shared file systems become unreachable |
| Data and streaming | BigQuery Data Transfer Service, Managed Service for Apache Kafka | Event pipelines and data feeds stall |
Revolut, Lloyds, HSBC: UK Firms Hit by the GCP Outage
Revolut was hit hardest, with its app, cards, transfers, ATM withdrawals, currency exchange and share trading all affected. Lloyds, HSBC, Bank of Scotland, Royal Mail and Screwfix also reported disruption. Lloyds said similar issues were affecting other organisations, which suggests a common cause. So far, Revolut is the only company whose outage has been publicly linked to Google Cloud.
Revolut Outage: Why Cards Were Declined at the Till
In many banking outages, the app goes down, but cards keep working. On 20 October 2026, Revolut customers in the UK, France and Spain were turned away at supermarket tills and coffee counters.
Every card payment needs live approval from the bank’s own systems. When those systems are unreachable, the terminal declines the card, regardless of the account balance.
Revolut has more than 80 million customers worldwide, including 13 million in the UK. It confirmed that customer money and data stayed safe. Customers still couldn’t get to their own money, though, and at a checkout that matters more than the balance.
The CTO takeaway: Card authorisation is a revenue-critical path. If it depends on a single zone or region, a single cloud fault can prevent all customers from paying at once.
Why One GCP Zone Failure Spread Across europe-west2
A Google Cloud region is made up of zones, each with its own power, cooling and network. London’s europe-west2 has three. If one zone fails, the other two should keep your services running.
In practice, three weak points break that promise.
- Resources Locked to One Zone
Many GCP resources are created in a single zone by default. When that zone fails, they fail with it. The infographic below shows the most common ones and their regional alternatives.
- Shared Dependencies
An app can run in all three zones and still rely on one DNS setup, message broker or secrets store. If that component goes down, every zone that depends on it goes down too.
- Failover Nobody Has Tested
Failover that has only ever existed on an architecture diagram tends to fail the first time it is needed. Only regular testing under real load shows whether it works.
Google has traced the outage to a power event in a single zone, europe-west2-b. The errors and network failures it reported still spread across the whole europe-west2 region. Its full incident report should confirm which of these weak points played a part.

Why Status Pages Lag Behind Cloud Outages
On 20 October 2026, Revolut’s status page showed all systems as “operational”, while customers reported failed payments on social media. The page was later updated to show an incident affecting sign-ins, card payments, top-ups, and ATM withdrawals.
Status pages are usually updated by hand, once someone has confirmed the incident. Until then, customers fill the silence themselves, in public. AI providers face the same delay, as Deployflow’s Claude outage tracker shows.
Detect failure before your customers do. Synthetic checks, such as a test login or test card authorisation every minute, reveal a fault within moments. A provider’s dashboard may take far longer to change colour.
Keep monitoring out of the blast radius. Monitoring that runs in the same region as your apps can fail alongside them. Run alerting on separate infrastructure, and send it to channels your engineers already watch, such as Slack or Microsoft Teams.
Cloud Concentration Risk: FCA, PRA and DORA Rules Explained
For regulated firms, a cloud outage quickly becomes a compliance question. A hyperscaler region failing is exactly the kind of “severe but plausible” event regulators expect firms to have planned for.
UK: FCA Operational Resilience Rules
Under the FCA’s operational resilience rules (PS21/3), firms must:
- identify their important business services
- set an impact tolerance for each one
- prove they can stay within it during severe disruption
The deadline to comply was 31 March 2025. Blaming the cloud provider won’t satisfy a supervisor.
UK: Critical Third Parties Regime
Since 1 January 2025, HM Treasury has been able to designate key suppliers to the financial sector as critical third parties. Under the joint regulator rules (PS16/24), regulators can then oversee them directly. Designation doesn’t move responsibility for resilience away from the firms that rely on them.
EU: DORA
The Digital Operational Resilience Act (DORA) has applied since 17 January 2025. It requires firms to manage ICT third-party risk, test their resilience and keep a workable exit plan for critical providers. It also sets strict deadlines for reporting major ICT incidents. Revolut’s EU banking business is licensed in Lithuania, so an outage like this one can fall under DORA as well as UK rules.
Regulated teams need infrastructure designed around these rules from the start. Deployflow’s fintech DevOps services are built for FCA-regulated environments.
The same risk applies outside finance. Retailers, logistics firms and SaaS companies with everything in one region of one provider should have that dependency on the board’s risk register.

Five Fixes CTOs Should Make After the GCP Outage
Each fix below can start this week. Assign an owner and agree on what “done” looks like before the next incident tests it for you.
| # | Fix | Suggested owner | Done when |
| 1 | Map every workload to its zone and region. Flag any resource that exists in one zone only. | Platform lead | Every production service has a documented location and failure domain |
| 2 | Test failover on a game day. Take one zone offline in staging, or in production during a planned window. | SRE or DevOps lead | Recovery time is measured and falls within your impact tolerance |
| 3 | Move revenue-critical journeys to multi-region. Start with payments, login and checkout. A warm standby in a second region is a practical first step. | Solutions architect | Each critical journey can run from a second region |
| 4 | Remove hidden single points of failure. Check DNS, identity, secrets, message queues and managed databases. | Platform and security leads | No shared dependency is limited to one zone |
| 5 | Review Google’s incident report against your architecture. Compare its failure chain with your own setup once it is published. | CTO | Risk register and resilience tests updated to reflect the findings |
Three Questions for Your Next Board Risk Review
- Which of your important business services would stop if one cloud zone failed?
- When did your team last prove failover works, and how long did recovery take?
- Which of your critical suppliers run in the same cloud region as you?
The third question matters more than most boards realise. A firm can spread its own workloads perfectly and still go down because of a payments, identity, or messaging supplier that relies on a single region.

Multi-Zone, Multi-Region or Multi-Cloud: Which Does Your Business Need?
Each extra layer of redundancy adds cost and complexity. Match the level to what each service is worth to the business.
Choose multi-zone for every production workload. It protects against a single zone failing at low extra cost. Treat it as the baseline across your whole estate.
Add multi-region for the journeys that earn or lose money. Payments, login and checkout justify the medium-to-high cost of surviving a full regional outage. Most estates need it for only a handful of services. During the London outage, Google advised affected customers to move workloads to other regions where feasible. That advice only helps teams that built for it in advance.
Reserve multi-cloud for regulatory or exit requirements. Running across two providers is the most expensive option and the hardest to operate. It makes sense when a regulator or contract demands a credible exit route.
If you are comparing providers, Deployflow’s AWS, Azure and GCP security comparison is a great place to start.
GCP Outage Tracker: Major Google Cloud Incidents
Newest incidents first. Each new major outage is added here.
| Date | Region | What failed | Duration | Root cause |
| 20 October 2026 | europe-west2 (London) | Multiple services, traced to zone europe-west2-b. Revolut, Lloyds, HSBC and others disrupted | Power mitigated at 11:36 UTC; services recovering | Power event in zone europe-west2-b (full report pending) |
| 12 June 2025 | Global | API requests failed across many Google Cloud and Workspace products | Several hours | Faulty update to Service Control, Google’s API policy system |
| 24 October 2024 | europe-west3 (Frankfurt) | Compute, Kubernetes, Pub/Sub and other services in one zone | 12 hours 39 minutes | Power failure and cooling issue in zone europe-west3-c |
| 25 April 2023 | europe-west9 (Paris) | Extended outage across the zone europe-west9-a, with wider regional impact | Days for the worst-hit zone | Water leak leading to a fire in a data centre |
Protect Your Business From the Next Google Cloud Outage
The 20 October outage won’t be the last. The firms that recover fastest are the ones that prepared before it happened.
Deployflow helps CTOs and IT leaders:
- Find single-zone risks. Deployflow’s cloud management services team maps your workloads against zone and region failures and delivers a prioritised remediation plan.
- Prove failover works. Deployflow engineers design failover, run game days and set reliability targets aligned with your impact tolerances.
- Spot problems early. Sizif adds AI-driven monitoring and Slack or Teams alerting to your existing Zabbix and Wazuh setup.
Book a free 30-minute consultation and find out which of your services would stop if a single cloud zone failed tomorrow.
Google Cloud Outage: Frequently Asked Questions
Does Google Cloud pay compensation for outages?
No. Google Cloud does not pay cash compensation for outages.
Customers can claim service credits when a product falls below the uptime promised in its Service Level Agreement (SLA). Credits are a percentage of the monthly bill for the affected service, and they must be requested within the time limit set in each SLA. They rarely match the real cost of lost sales, regulatory fines or customer churn. Treat the SLA as a limited commercial safeguard. Your own architecture, insurance and supplier contracts should cover the business impact of downtime.
How can I check if Google Cloud is down?
Check the Google Cloud Service Health dashboard first. It lists active incidents by product and region. Signed-in customers can also use Personalized Service Health in the Google Cloud console, which shows only the incidents affecting their own projects. Those alerts can be sent to email, Slack or PagerDuty through Cloud Monitoring. Third-party trackers such as Downdetector collect user reports, which often appear before official confirmation. For production systems, run your own monitoring as well, because provider dashboards can lag behind the first signs of trouble.
What is the difference between RTO and RPO?
Recovery Time Objective (RTO) is the longest a service can stay down before the impact becomes unacceptable. Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that the business can afford to lose.
An RTO of one hour means the service must be back within an hour. An RPO of five minutes means backups or replication must never fall more than five minutes behind. Together, these two targets decide how much to invest in failover and replication. UK financial firms should align both with their FCA impact tolerances.
What is the difference between high availability and disaster recovery?
High availability keeps a service running through small, expected failures, such as a lost server or zone. It usually works automatically, with no manual action. Disaster recovery restores a service after a major event, such as the loss of an entire region, a ransomware attack, or data corruption.
High availability relies on redundancy across zones. Disaster recovery relies on backups, replicas in another region and a tested recovery plan. Most businesses need both. A regional cluster survives a zone outage, but it cannot help if the data itself is deleted or encrypted.
Is Google Cloud less reliable than AWS or Azure?
There is no reliable public evidence that Google Cloud is less reliable than AWS or Azure. All three have suffered major outages. AWS had a large incident in its US-East-1 region on 20 October 2025, exactly a year before the London outage. Microsoft’s Azure Front Door service failed later that same month. Each provider publishes its own incident history, but they measure and report it in different ways, making direct comparisons difficult. The more useful question is how well your architecture copes when any provider has a bad day.

Yes, Google Cloud went down in London. A major Google Cloud outage hit the europe-west2...
read full article

ISO 42001 is the international standard that demonstrates your organisation governs AI properly, and enterprise...
read full article

Claude went down across every surface on 29 September 2026. From 14:00 to 14:59 UTC,...
read full article

