Google Cloud falla en Londres: qué hay detrás de una mañana de errores en la nube
Google Cloud sufrió una incidencia en Londres que afectó a varios servicios. El episodio recuerda que una aplicación puede depender de infraestructura situada a miles de kilómetros de sus usuarios.
La mañana del 20 de octubre de 2026 comenzó con problemas en una parte de la infraestructura europea de Google Cloud. La compañía situó la incidencia en Londres, en la región denominada europe-west2, y comunicó un aumento de errores y fallos intermitentes de red.
El registro incluye productos como Compute Engine, Kubernetes Engine, Cloud Run, Cloud Storage y Pub/Sub, entre otros. Se trata de infraestructura utilizada para ejecutar aplicaciones, almacenar información y conectar procesos. Aviso oficial del incidente.
Para entender qué significa esto para una empresa, conviene mirar más allá del mensaje de error: dónde se ejecutan sus herramientas, de qué servicios dependen y qué ocurre cuando una de esas piezas deja de responder.
La cronología: el incidente comenzó a las 08:08 en España
Estas son las referencias temporales del aviso consultado, convertidas a hora de España peninsular:
| Hora | Qué recoge el aviso |
|---|---|
| 08:08 del 20 de octubre | Inicio del incidente señalado por Google. |
| 10:35 | Actualización: el equipo continuaba investigando y no ofrecía una solución alternativa. |
| 11:30 | Hora prevista para otra comunicación, no un plazo de recuperación. |
El registro original utiliza horario del Pacífico: su fecha de inicio figura como 19 de octubre a las 23:08 PDT. A las 10:35 españolas habían transcurrido dos horas y 27 minutos desde el comienzo indicado. Cronología de Google Cloud.
La diferencia horaria explica por qué algunas referencias pueden situar el mismo episodio en días distintos.
Qué significa que falle una región de Google Cloud
Una región es una ubicación geográfica en la que un proveedor organiza su infraestructura. Dentro de ella existen zonas, concebidas como ámbitos separados de fallo.
Por eso, decir que una empresa utiliza Google Cloud no permite saber por sí solo si está afectada. También importa dónde tiene desplegados sus recursos y cómo ha preparado su aplicación para soportar interrupciones. Google distingue recursos zonales, regionales y multirregionales, con diferentes alcances y mecanismos de disponibilidad. Documentación sobre regiones y zonas.
Para el usuario final, esa geografía suele ser invisible. Puede abrir una aplicación desde Madrid mientras parte del trabajo se ejecuta en Londres. Si esa dependencia falla, la distancia física del usuario no evita el problema.
Cómo puede llegar el problema a una web o una aplicación
Una aplicación suele reunir varias piezas: la interfaz que vemos, los procesos que responden a nuestras acciones y los sistemas que guardan los datos. Algunas funciones también dependen de servicios externos.
Google explica en su guía de fiabilidad que una única dependencia sin redundancia puede comprometer la disponibilidad de una aplicación completa. Tener varias piezas funcionando no basta si una operación imprescindible depende de un solo recurso. Guía de diseño de infraestructura fiable.
Imaginemos una herramienta de reservas. La página principal podría abrirse mientras falla la consulta de disponibilidad. También podría ocurrir que los visitantes siguieran navegando, pero el equipo no pudiera acceder a una función de gestión.
Estos son ejemplos de cómo se manifiestan las dependencias técnicas, no una descripción de empresas concretas afectadas en este episodio.
Qué sabemos de la causa y qué sigue pendiente
Google atribuyó la interrupción a un incidente eléctrico en la zona europe-west2-b. El registro sitúa el cierre del incidente a las 16:00 del 20 de octubre, hora de España peninsular. En su última comunicación, de las 16:03, la compañía indicó que había mitigado el impacto para la mayoría de los clientes y seguía atendiendo a un número muy reducido de afectados. El análisis técnico detallado seguía pendiente. Estos datos no permiten afirmar que hubiera un ciberataque, pérdida de datos o una caída global de Google.
Conviene distinguir tres cosas: el síntoma observado, la explicación inicial y el análisis técnico posterior. Que una conexión falle permite comprobar que existe un problema; no revela automáticamente qué equipo, suministro o cambio lo originó.
La precisión también importa al hablar del alcance. Una lista de productos vinculados a un incidente no significa que todos sus clientes, en todas las regiones, hayan quedado sin servicio.
Un antecedente en Londres, con una causa documentada
Google ya publicó un informe sobre otro incidente en Londres ocurrido el 12 de agosto de 2024. En aquel caso, explicó que un fallo en equipos eléctricos de una subestación provocó la pérdida de alimentación principal y de respaldo en un punto de presencia de su red.
Aquel episodio generó problemas de conectividad y latencia. El impacto registrado para Google Cloud duró dos horas y 12 minutos. Informe oficial de agosto de 2024.
Es un antecedente útil para entender la dimensión física de la nube: detrás del servicio hay electricidad, equipos y conexiones. No demuestra que la incidencia de octubre de 2026 tenga el mismo origen.
La pregunta para un negocio: qué ocurre si una dependencia falla
Para quienes trabajamos con páginas web y herramientas digitales, estos episodios plantean una cuestión práctica: cuánto tiempo puede estar interrumpida una función antes de convertirse en un problema para el negocio.
La documentación de Google recomienda evitar puntos únicos de fallo y distribuir recursos según las necesidades de disponibilidad. También advierte que mantener la continuidad entre regiones requiere medidas adicionales; desplegar una aplicación en varios lugares no resuelve por sí solo todas sus dependencias. Recomendaciones de arquitectura y continuidad.
Mi lectura es que la respuesta debe ser proporcional. Una web informativa y una plataforma que gestiona operaciones urgentes no tienen las mismas necesidades ni el mismo presupuesto. En ambos casos, ayuda saber quién comprueba el servicio, quién informa de la incidencia y qué alternativas existen mientras se recupera.
La nube permite delegar infraestructura. La continuidad del negocio sigue requiriendo decisiones, comprobaciones y un plan.
Actualizado el 21 de octubre de 2026 con el registro oficial de Google Cloud, incluida la comunicación del 20 de octubre a las 16:03, hora de España peninsular. La cronología inicial recoge los avisos disponibles durante la mañana; la sección sobre la causa incorpora la recuperación posterior. Imagen de portada: ilustración conceptual de Londres e infraestructura digital generada con IA; no muestra las instalaciones afectadas ni reconstruye el incidente.
