Caída de Google Cloud: restaurar la infraestructura no devuelve todos los servicios a la vez

Un incidente localizado en la región de Londres

Varios servicios de Google Cloud sufrieron problemas el 20 de octubre de 2026 en la región de Londres, identificada como europe-west2. La cronología oficial sitúa el inicio del incidente el 19 de octubre a las 23:08 y su final el 20 de octubre a las 7 horas, en horario del Pacífico. Esto corresponde a las 8:08 y las 16 horas de París del 20 de octubre. Google atribuye el origen a un incidente eléctrico en la zona europe-west2-b y describe indisponibilidad de servicios y errores de red intermitentes.

En su última actualización, Google indica que los efectos estaban corregidos para la mayoría de los clientes, con un número muy pequeño de situaciones todavía atendidas por sus equipos. El proveedor anuncia también un análisis del incidente tras concluir su investigación interna. Clasificar el evento como cerrado debe interpretarse, por tanto, con las precisiones de esa actualización. No significa que cada aplicación que utiliza los servicios afectados recupere simultáneamente todas sus funciones ni que cada cliente haya sufrido exactamente la misma interrupción.

Funciones bancarias todavía afectadas

Cuando se consultó su página de estado el 20 de octubre, Revolut todavía mostraba funciones parcialmente indisponibles. Esta página distingue los diferentes servicios ofrecidos a particulares y empresas. Un incidente puede tener consecuencias distintas sobre el acceso, los pagos, las transferencias o la consulta de determinada información. La presencia de un mensaje de error no permite determinar por sí sola el resultado de una operación concreta. Hay que remitirse al estado comunicado por la entidad y a la información propia de la transacción afectada.

La recuperación de una infraestructura y la de las aplicaciones que aloja son etapas distintas. Tras restablecer un componente, una aplicación puede todavía necesitar reanudar procesos pendientes, recuperar conexiones o comprobar la coherencia de sus operaciones. Esta explicación general no constituye un diagnóstico detallado de la arquitectura de Revolut. Los elementos necesarios para tal diagnóstico deberán proceder de los informes de las empresas afectadas. Solo permite comprender por qué una señal de recuperación en una capa previa no equivale al retorno instantáneo de todos los recorridos de usuario.

Una pantalla inaccesible no describe el saldo de los activos

En servicios financieros y cripto, debe distinguirse el acceso a una interfaz, la ejecución de una operación y la custodia de activos. Una aplicación que no responde puede impedir consultar un saldo sin que ese síntoma demuestre por sí solo una desaparición de fondos. A la inversa, una pantalla de acceso funcional no garantiza que estén disponibles todos los pagos y retiradas. Las páginas de estado ayudan a identificar el alcance de las funciones afectadas; no sustituyen el registro de una operación ni la respuesta del proveedor sobre un caso individual.

La caída tampoco permite afirmar que una red blockchain y todas las aplicaciones que dan acceso a ella compartan la misma disponibilidad. Las interfaces y los proveedores pueden depender de infraestructuras comunes, incluso cuando los activos utilizan una blockchain. La evaluación de continuidad debe abarcar cada componente realmente utilizado. Para este incidente, las referencias consolidadas siguen siendo la cronología publicada por Google, los estados de los servicios afectados y los análisis detallados que los operadores publiquen sobre las causas y las medidas correctoras.