Google Cloud Outage: Restoring the Infrastructure Does Not Bring All Services Online Simultaneously

A localized incident in the London region

Several Google Cloud services were disrupted on October 20, 2026, in the London region, identified as europe-west2. The official timeline places the start of the incident on October 19 at 23:08 and its end on October 20 at 07:00 Pacific Time. This corresponds to 08:08 and then 16:00 in Paris on October 20. Google attributes the cause to an electrical event in the europe-west2-b zone and describes a service unavailability along with intermittent network errors.

In its latest update, Google indicates that the effects were corrected for most customers, with a very small number of situations still being handled by its teams. The provider also announces an analysis of the incident after the conclusion of its internal investigation. The classification of the event as closed should therefore be read with the clarifications of this update. It does not mean that every application using the affected services regains all its functions simultaneously, nor that every client experienced exactly the same interruption.

Banking functions still disrupted

When checking its status page on October 20, Revolut still displayed partially unavailable functions. This page distinguishes the different services offered to individuals and businesses. An incident can therefore have different consequences on login, payments, transfers, or access to certain information. The presence of an error message alone does not allow one to determine the fate of a particular transaction. One must refer to the status communicated by the institution and to the information specific to the transaction in question.

The restoration of an infrastructure and the restoration of the applications it hosts correspond to different steps. After a component is brought back online, an application may still need to resume pending processes, re‑establish connections, or verify the consistency of its operations. This general explanation does not constitute a detailed diagnosis of Revolut’s architecture. The elements required for such a diagnosis must come from the reports of the concerned companies. It only helps to understand why an upstream recovery signal does not equal an instant return of all user journeys.

An inaccessible screen does not describe the balance of assets

For financial and crypto services, one must distinguish access to an interface, execution of an operation, and custody of assets. An application that does not respond can prevent viewing a balance without that single symptom proving a loss of funds. Conversely, a functional login screen does not guarantee that all payments and withdrawals are available. Status pages help identify the scope of affected functions; they do not replace the statement of a transaction or the provider’s response on an individual case.

The outage also does not allow one to claim that a blockchain network and all applications that access it share the same availability. Interfaces and providers may depend on common infrastructures, even when assets use a blockchain. Continuity assessment must therefore focus on each component actually used. For this incident, the consolidated information to retain remains the timeline published by Google, the status of the affected services, and the detailed analyses that operators will publish on the causes and corrective measures.