A power cut became a seven-minute countdown
Around 07:08 BST on a Tuesday, a local grid failure struck Google Cloud’s europe-west2-b zone in London. UPS batteries immediately engaged, a textbook response. However, neither the primary nor the backup generator controller initiated the diesel generators, leaving the facility reliant on battery power.
That seven-minute window proved critical. The data center ran on batteries for roughly seven minutes before power depleted, plunging the entire zone into darkness. Critically, the batteries did not fail; the generator-start systems did, creating a cascade of unexpected outages.
Revolut, a fintech giant serving millions, immediately felt the impact. Users reported widespread issues:
- Failed logins
- Blocked money transfers
- Declined card payments
Revolut initially cited a "service disruption" before attributing the extensive downtime to Google Cloud. The incident quickly underscored the fragility of relying on even the most sophisticated cloud infrastructure when a single point of failure—like a generator controller—can trigger such significant disruption.
The two healthy zones weren’t healthy enough
Multi-zone regions promise resilience: if one zone fails, workloads shift to the others. Google Cloud’s europe-west2 region in London has three such zones (a, b, and c). When zone b went dark, the system should have seamlessly failed over to a and c, maintaining service.
Instead, the sudden surge of traffic overloaded the remaining infrastructure. This wasn't a simple switch; it was a capacity problem and a coordination nightmare. Cross-zone dependencies meant some services in zones a and c remained stuck, awaiting components or state still associated with the offline zone b.
The engineering lesson is stark: redundancy is only effective if zones are truly independent and possess enough headroom to absorb a realistic failover storm. Rate limits, graceful degradation, and rigorously tested recovery plans are critical to preventing a "thundering herd" from taking down an entire region.
Google recovered before Revolut did
Google’s quick infrastructure recovery did not translate to immediate service restoration for its customers. Google reported that most clients were back online roughly six to eight hours after the incident started, between 13:00–15:00 BST. Revolut, however, did not announce full service restoration until 18:40 BST, a significant lag of several hours.
This disparity reveals a critical distinction: restoring cloud capacity does not instantly clear a client’s operational backlog. Even with compute and storage available, a financial institution like Revolut faces complex challenges. Reconciling transaction states, clearing payment backlogs, and normalizing every application dependency—from card payments to login services—takes time and careful sequencing.
The outage extended beyond Revolut. Reports indicated broader disruption across other UK institutions and services, including:
- Lloyds
- Halifax
- Remote court hearing video links
This wider impact underscores a fundamental vulnerability of shared cloud infrastructure. A single-zone failure in europe-west2-b cascaded into a widespread service problem, demonstrating how interconnected dependencies can turn a localized power event into a national headache. For further details on incident status, consult the Google Cloud Service Health Dashboard. Interestingly, regulators have taken notice, with the Bank of England of England and the FCA receiving inquiries about the incident’s notification timeline.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
A cloud outage is now a banking risk
Google Cloud’s designation as a critical third party to the UK financial system in July fundamentally changes the stakes. After the outage, the Treasury Committee chair immediately sought answers from the Bank of England of England and the FCA regarding notification timelines. This isn't just a technical glitch; it's a systemic risk.
Financial firms now face a stark question: how much resilience is enough? When a cloud provider, an entire region, or even an application’s own architecture becomes a point of concentration, firms must scrutinize their exposure. Multi-region designs offer a path to reduced risk but introduce significant trade-offs in cost, latency, and complex data management.
For customers and builders, practical lessons emerge. During incidents, consistently check Google Cloud’s service health dashboard—it offers the most current information. Engineering teams must move beyond assumptions; test zone loss, validate failover capacity, and simulate degraded operating modes. Multi-zone deployment alone does not guarantee continuity.
Frequently Asked Questions
Why did Revolut go down during the Google Cloud outage?
A London data center lost power after primary and backup generator controllers failed. Traffic shifted to the remaining zones, which were also affected by overload and dependencies on the offline zone.
How long did the Google Cloud London outage last?
Google said most affected customers had recovered around six to eight hours after the incident began. Revolut said its services were back later, at roughly 18:40 BST.
Why didn’t Google Cloud’s other London zones prevent the disruption?
The remaining zones faced a sudden surge of failover traffic, while some services still depended on components tied to the failed zone.
What does the outage mean for UK financial services?
It highlights how disruption at a major cloud provider can affect financial services and why regulators are scrutinizing critical third-party providers.