Google Cloud’s London Outage: Recovery Begins After Power Event Disrupts Services

Google says services are recovering after a power event disrupted its London cloud infrastructure on October 20, with wider effects on apps and banking services. The incident highlights the difference between restoring power, recovering existing workloads and confirming that every affected customer function is working normally.

Google Cloud’s London disruption has moved into a recovery phase, but the company’s latest incident update reviewed for this report stops short of declaring the entire event resolved. Google reported recovery for most workloads in its europe-west2 region from 12:10 UTC on Tuesday, October 20. The underlying power event had been mitigated, while service restoration remained the task.

The incident began at 23:08 Pacific time on October 19, equivalent to 06:08 UTC and 08:08 in Belgrade on October 20. Google’s 12:44 UTC update still described unavailable services in the europe-west2-b zone and possible elevated errors elsewhere in the London region. It promised another update rather than an unconditional all-clear. Google’s original incident record is the primary source for the changing status.

What Google has actually confirmed

The incident record identifies a power event in one London availability zone. Its listed effects cover multiple services, including computing, storage, networking and managed application infrastructure. Google said it was prioritising recovery of existing workloads and warned earlier that creation of new workloads might remain restricted during that process. Those statements should not be shortened to a claim that every Google service worldwide stopped working.

The geographical distinction is important. A failure can be concentrated in a particular infrastructure location while affecting people in other countries whose applications depend on that location. The user’s physical location and the application’s hosting location are different facts. A customer outside Britain can therefore experience a London-region incident without the same failure occurring in the customer’s own country.

The reverse is also true: a broad list of reports from different countries does not establish that every regional cloud facility failed. A shared dependency can produce effects in many places. Determining the extent of this incident requires the provider’s location-specific account and statements from affected services, rather than treating a map of complaints as a map of broken infrastructure.

The disruption reached customer-facing services

The Associated Press reported interruptions affecting several UK banks and carried a Revolut statement saying that customer money and data were safe. That assurance belongs to Revolut’s statement; it is not an independent audit of every institution’s systems. The report also noted that the connection between some other European outages and this incident was unclear. AP’s October 20 account distinguishes the confirmed disruption from that uncertainty.

El País separately reported difficulties affecting some Revolut customers’ access, payments and transfers during the disruption. That is evidence of the customer-facing consequences, rather than a technical explanation for each failed action. Different functions can depend on different components and can recover at different times. The newspaper’s report provides additional contemporary coverage.

For readers, three states should remain separate: a provider has acknowledged an infrastructure incident, an application operator has acknowledged service disruption, and an individual action has a confirmed outcome. Evidence of one does not automatically answer the others. In particular, a temporary failure to display information is not, by itself, proof that stored information has been lost.

A region and a zone are different failure domains

Google’s infrastructure documentation describes regions and zones as building blocks for deployment. Its Compute Engine guidance recommends distributing fault-tolerant applications across multiple zones and, where needed, multiple regions. That guidance is about architecture chosen in advance, not a promise that every application using Google Cloud is automatically distributed in this way. The regions-and-zones documentation explains the distinction.

Google’s reliability guide further distinguishes zonal, regional, multi-region and global resources. A resource’s scope affects which infrastructure failures it is designed to tolerate. An application can combine resources with different scopes, so the resilience of the complete application depends on how those pieces fit together. The reliability building-blocks guide provides that framework.

That is why the presence of several zones in a region does not settle the question of how a particular service will behave. An application may depend on a component in one zone, require sufficient spare capacity elsewhere, or need an operational decision before traffic moves. The current public incident record does not establish the architecture of every affected customer. It would be speculative to name a particular design mistake without that evidence.

Restoring power and restoring a service are separate milestones

A power event can be mitigated before every dependent workload is ready to serve requests. Infrastructure services, databases, application processes and network paths may have to return to a usable state in a controlled sequence. Recovery can also involve prioritising workloads already running before the incident over the creation of new ones, as Google described in its update.

This does not mean the recovery effort has failed when a later status message still lists symptoms. It means the relevant milestone needs to be named precisely. Restored electrical supply, recovering infrastructure, an available application and successful customer transactions describe different layers. A meaningful all-clear should identify which layer has recovered and whether any exceptions remain.

The same care applies to tentative recovery estimates. An estimate is useful information about a responder’s current expectation, but it is not a completed result. If a later update changes the estimate or provides a more limited account of recovery, coverage should use the later information. This article therefore reports the confirmed recovery phase rather than treating an earlier target time as proof of complete restoration.

Backups do not replace an availability plan

Google’s disaster-recovery planning guide separates recovery time objectives from recovery point objectives. The first concerns how long an interruption can be tolerated; the second concerns how much recent data loss an organisation is prepared to tolerate. Those are planning targets, rather than measurements of what happened in this incident. The disaster-recovery planning guide explains why both matter.

A backup can preserve a recoverable copy of data without keeping an application continuously available. Conversely, an application can remain reachable while a particular function or dependency is impaired. Resilience planning has to connect the organisation’s required service to the infrastructure and data needed to deliver it. Merely identifying that a backup exists does not show that recovery can meet the intended time target.

Google’s infrastructure-outage guidance also discusses the difference between components that continuously process operations and components used to manage or configure systems. A recovery design needs to consider which dependencies remain necessary during an outage, not just during normal operation. Its infrastructure-recovery guidance provides that additional architectural context.

Moving a workload is not always an immediate option

Google’s incident page suggested moving an affected workload to another available location where feasible. The qualification matters. A workload may depend on data, capacity, permissions and services that are not already prepared in a second location. An incident-time move can therefore require more than changing one setting, even where another zone is functioning.

Data-location requirements can add another constraint. Google’s guide to recovery for locality-restricted workloads examines designs that must preserve location requirements while addressing infrastructure failure. It describes how distributing resources across zones can help isolate many physical failures without assuming that an organisation is free to move data anywhere. The locality-restricted recovery guide explains that trade-off.

These are general design considerations, not claims that a particular affected bank or application chose an inadequate arrangement. An assessment of that kind would need the customer’s architecture, requirements and incident findings. The public status page alone cannot supply them.

More providers can add options and complexity

Google’s business-continuity guidance for hybrid and multicloud systems recommends documenting infrastructure, failover and recovery procedures around the organisation’s recovery objectives. The relevance is the preparation, rather than a claim that buying a second cloud service automatically supplies a working fallback. The continuity-patterns guide describes the planning requirement.

A second provider can be useful only if the relevant application, data and access arrangements can operate there when needed. An organisation also has to know who is responsible for initiating the switch, how it will check the outcome and how normal operation will eventually be restored. Those questions belong in an exercised plan, rather than a list of suppliers that has never been tested as a complete service.

Google’s resource-scope documentation offers another practical distinction: a global resource can be accessible from different regions without making every associated computing instance global. Resource availability and application availability should therefore be examined at the level of actual dependencies. The resource-scope reference helps identify which component is being discussed. That level of precision will matter when customers and the provider eventually assess this incident.

What to watch as recovery continues

The next important information is a confirmed resolution notice, any remaining service-specific restrictions and a subsequent account of the cause and impact. A public incident summary can change as engineers learn more. Google’s service-health documentation explains the purpose of the public dashboard and the distinction between broad incident reporting and more customer-specific support information. The dashboard documentation is useful when interpreting those updates.

The verified story at this stage is a power-related London-zone incident with consequences across dependent services, followed by recovery for most workloads. It is not a confirmed worldwide Google outage or an established loss of customer funds. Those stronger claims require evidence that the reviewed sources do not provide.

Our earlier report on cloud independence testing examines another set of infrastructure questions. Independence, geographic distribution, data protection and service availability overlap, but they answer different needs. Today’s disruption demonstrates why each needs an explicit definition and a testable plan.