Historial de interrupciones de Google Maps Platform

1. 20 de octubre de 2026 a las 8:35 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos experimentando un problema con múltiples servicios en europe-west2 a partir del lunes, 2026-10-19 23:08 PDT. Nuestro equipo de ingeniería continúa investigando el tema. Ofrecemos una actualización para el martes, 2026-10-20 02:30 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Múltiples servicios de Google Cloud están experimentando errores elevados e fallos de red intermitentes en la región europe-west2. *Trabajando* Nada por ahora

2. 20 de octubre de 2026 a las 9:24 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos experimentando un problema con múltiples servicios en europe-west2 a partir del lunes, 2026-10-19 23:08 PDT. Nuestro equipo de ingeniería continúa investigando el tema. Ofrecemos una actualización para el martes, 2026-10-20 04:00 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Varios servicios de Google Cloud están experimentando errores elevados y fallas intermitentes de red en la región europe-west2. Nota: Looker Studio no es impactado por este outage. *Trabajando* Si es factible, el cliente afectado puede intentar migrar su carga de trabajo impactado a otro lugar disponible (zona o región).

3. 20 de octubre de 2026 a las 11:00 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos experimentando un problema con múltiples servicios en europe-west2 a partir del lunes, 2026-10-19 23:08 PDT. Nuestro equipo de ingeniería continúa investigando el tema. Ofrecemos una actualización para el martes, 2026-10-20 05:00 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Varios servicios de Google Cloud están experimentando errores elevados y fallas intermitentes de red en la región europe-west2. Nota: Looker Studio no es impactado por este outage. *Trabajando* Si es factible, el cliente afectado puede intentar migrar su carga de trabajo impactado a otro lugar disponible (zona o región).

4. 20 de octubre de 2026 a las 11:12 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos experimentando un problema con múltiples servicios en europe-west2 a partir del lunes, 2026-10-19 23:08 PDT. Debido a un evento de poder, habíamos sufrido una salida dentro de la zona europe-west2-b. El evento de energía está mitigado. La mitigación parcial de los servicios de infraestructura se observará en los próximos 30 minutos y los servicios restantes se mitigarán allí después. Ofrecemos una actualización para el martes, 2026-10-20 05:00 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Los servicios de Google Cloud no están disponibles en la zona europe-west2-b; algunos servicios en la región europe-west2 pueden experimentar errores elevados y problemas de red intermitentes. *Trabajando* Si es factible, el cliente afectado puede intentar migrar su carga de trabajo impactado a otro lugar disponible (zona o región).

5. 20 de octubre de 2026 a las 11:58 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos experimentando un problema con múltiples servicios en europe-west2 a partir del lunes, 2026-10-19 23:08 PDT. Un evento de energía causó una salida dentro de la zona europe-west2-b. El evento de energía está mitigado. Estamos viendo la recuperación de los servicios y estamos priorizando la recuperación de las cargas de trabajo existentes. Los clientes no pueden crear aún nuevas cargas de trabajo. La recuperación total de las cargas de trabajo existentes debe completarse, provisionalmente para el martes 2026-10-20 06:00. Ofrecemos una actualización para el martes, 2026-10-20 06:00 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Los servicios de Google Cloud no están disponibles en la zona europe-west2-b; algunos servicios en la región europe-west2 pueden experimentar errores elevados y problemas de red intermitentes. *Trabajando* Si es factible, el cliente afectado puede intentar migrar su carga de trabajo impactado a otro lugar disponible (zona o región).

6. 20 de octubre de 2026 a las 12:44 UTCresolved

   **Summary** Varios servicios están experimentando problemas en la región europe-west2. **Descripción** Estamos viendo la recuperación de servicios para la mayoría de las cargas de trabajo en europe-west2 al martes, 2026-10-20 05:10 PDT. Ofrecemos una actualización para el martes, 2026-10-20 07:00 PDT con los detalles actuales. Nos disculpamos con todos los afectados por la perturbación. *Síntomas* Los servicios de Google Cloud no están disponibles en la zona europe-west2-b; algunos servicios en la región europe-west2 pueden experimentar errores elevados y problemas de red intermitentes. *Trabajando* Si es factible, el cliente afectado puede intentar migrar su carga de trabajo impactado a otro lugar disponible (zona o región).

7. 20 de octubre de 2026 a las 14:03 UTCresolved

   **Summary** Varios servicios estaban experimentando problemas en la región europe-oeste2. **Descripción** La cuestión con productos GCP impactados ha sido mitigada para la mayoría de los clientes y se cree que está afectando actualmente a un número muy pequeño de clientes y nuestro Equipo de Ingeniería está trabajando en ello. Si tiene preguntas o son impactadas, por favor abra un caso con el Equipo de Soporte y trabajaremos con usted hasta que se resuelva este problema. No se proporcionarán más actualizaciones aquí. Publicaremos un análisis de este incidente una vez que hayamos completado nuestra investigación interna. Le agradecemos su paciencia mientras estamos trabajando en resolver el problema. *Síntomas* Los servicios de Google Cloud no estaban disponibles en la zona europe-west2-b; algunos servicios en la región europe-west2 podrían experimentar errores elevados y problemas de red intermitentes. *Trabajando* Ninguna como la cuestión se ha mitigado.

8. 22 de octubre de 2026 a las 8:42 UTCresolved

   ## Preliminary Incident Report Reconocemos que los servicios de Google Cloud son críticos para su organización, y sinceramente nos disculpamos por la perturbación que este incidente puede haber causado a su negocio. Estamos trabajando para abordar la causa raíz y evitar que esto ocurra en el futuro. Tenga en cuenta que esta información se basa en nuestro mejor conocimiento en el momento de la publicación y está sujeta a cambios a medida que continúa nuestra investigación. Un informe final de incidentes con acciones preventivas será publicado una vez que nuestra investigación esté completa. Si usted ha experimentado un impacto fuera de lo que se enumera a continuación, por favor diríjase a Google Cloud Support utilizando [**https\://cloud.google.com/support**](https://cloud.google.com/support). ## Date/Time of the Issue Incident Start:19 Oct 2026 23:00 US/Pacific / 20 Oct 2026 07:00 BST Incident End: 20 Oct 2026 05:10 US/Pacific / 20 Oct 2026 13:10 BST Duración: 6 horas, 10 minutos ## Summary El lunes 19 de octubre de 2026 (martes, 20 de octubre BST), múltiples servicios de Google Cloud Platform en la región europe-oeste2 experimentaron interrupciones de servicio, tasas de error elevadas, timeouts de la interfaz de programación de aplicaciones (API) y procesamiento de latencia por una duración de 6 horas y 10 minutos. La interrupción fue provocada por una interrupción de la energía eléctrica en el centro de datos que albergaba la zona de disponibilidad europe-west2-b, que tomó temporalmente servidores de host físicos, hardware de enrutamiento de red y sistemas de almacenamiento fuera de línea. This subsequently caused secondary failover and queuing delays across unimpacted regional infrastructure. ## Preliminary Root Cause El incidente fue desencadenado cuando se produjo una interrupción de la red eléctrica en el centro de datos que albergaba la zona de disponibilidad europe-west2-b. Para mantener la energía continua durante la interrupción, la transferencia automática a los sistemas de energía de copia de seguridad de las instalaciones fue activada inmediatamente. La carga de la instalación se transfirió a los bancos de baterías de suministro de energía ininterrumpida (UPS) durante la secuencia inicial de generadores diesel de emergencia in situ. El sistema de automatización programable de control lógico (PLC) (ambas PLC primarias y de respaldo) no inició las operaciones lógicas automáticas de inicio/transferencia de los generadores, evitando que los generadores de respaldo asuman la carga. Cuando las reservas de baterías de UPS se agotaron, servidores de host físicos, tela de conmutación de red y arrays de almacenamiento locales dedicados a la energía perdida europe-west2-b y se desconectaron. La secuencia de eventos que llevaron al impacto del cliente fue la siguiente: * A las 22:53 US/Pacific (20 Oct, 06:53 BST), se produjo una perturbación eléctrica en la instalación de datacenter que alberga la zona de disponibilidad europe-west2-b, y un PLC (Programable Logic Controller) falla de arranque impidió que los generadores de emergencia de instalaciones asumieran la carga eléctrica. La carga de la instalación siguió siendo apoyada por los bancos de baterías de UPS hasta que las baterías se agotaron, a partir de las 23:00 US/Pacifico (20 Oct, 07:00 BST). * Cuando los servidores de anfitriones físicos, la infraestructura local de almacenamiento y el hardware de agregación de red en la energía perdida europe-west2-b, causó casos, réplicas de bases de datos y nodos de trabajadores en esa zona para volverse inmediatamente inalcanzables. * Los mecanismos regionales de tráfico y las aplicaciones de los clientes iniciaron una falla automatizada hacia la infraestructura disponible en las zonas de disponibilidad adyacentes de la región. * Llamadas de procedimientos remotos de zona cruzada desde aviones regionales de control de servicios dirigidos a metadatos y componentes de catálogo en la zona fuera de línea encontraron plazos, causando puestos iniciales de presentación de empleo y picos de latencia de API. * La repentina afluencia de las ejecuciones de consultas redirigidas, las deficiencias de la base de datos de alta disponibilidad y las cargas de trabajo calculadas saturated compute slots y capacidad de procesamiento en otras zonas de disponibilidad, creando colas elevadas de admisión, concluciones de falla de la base de datos retrasadas y errores intermitentes de 500 y 503 API en toda la región. Los ingenieros de Google han iniciado un análisis completo de causa raíz (RCA) y proporcionarán información adicional una vez que esté disponible. ## Remediation Los ingenieros de Google fueron alertados por la interrupción a través de sistemas de monitoreo automatizados y probers a las 23:08 US/Pacific el 19 Oct (20 Oct, 07:08 BST), que detectó ratios de errores de API elevadas, plazos de presentación de empleo y pérdida de capacidad de infraestructura en europe-west2-b. Los equipos de ingeniería se movilizaron inmediatamente para aislar la infraestructura afectada y comenzar la recuperación: * **Isolación comercial:** Los ingenieros de Google aislaron la zona de disponibilidad fuera de línea (europeo-west2-b) ajustando el servicio regional que se aleja de la infraestructura afectada, impidiendo que los clientes de la zona cruzada soliciten el tiempo fuera de los puntos finales fuera de línea. * ** Reprioritización de la carga de trabajo y salvaguardias de recursos:** Los ingenieros ajustaron las asignaciones de cronogramas y los límites de capacidad de toda la infraestructura sin restricciones para priorizar las reservas activas de los clientes, reducir la contención de recursos en las ranuras de ejecución y aliviar los retrasos en la cola para las cargas de trabajo regionales. * ** Restauración de podadoras:** Los ingenieros de instalaciones in situ llevaron a cabo una restauración agraciada de una fuente de alimentación de electricidad estable una vez que el suministro de utilidad estaba de vuelta, dentro de 1 hora. Después de esto, se centraron y completaron un reseteo y probaron los controladores de automatización de generadores de emergencia para restaurar la potencia de instalación. * **Reactivación progresiva de la infraestructura:** Ingenieros de Google reiniciaron sistemáticamente infraestructura y servicios de Google Cloud. * **Readmisión de Tráfico Controlado** Una vez verificada la integridad de la salud y el almacenamiento del sistema, los ingenieros ejecutaron la re-admisión de tráfico gradual y controlado de vuelta a la zona europe-west2-b permitiendo que los atrasos acumulados de trabajo se despejen sin problemas. Para 05:10 US/Pacific el martes, 20 Oct(13:10 BST), la disponibilidad de servicios se había recuperado para la gran mayoría de las cargas de trabajo de los clientes, y la resolución para la mayoría de los clientes en los servicios de Google Cloud Platform en la región fue confirmada. Tras la recuperación de una pequeña cola de las cargas de trabajo aisladas restantes, la notificación de cierre del incidente fue publicada por 07:03 US/Pacific (15:03 BST). ## Descripción del impacto Entre el lunes 19 oct 2026, 23:00 US/Pacifico (martes, 20 oct 2026, 07:00 BST) y el martes 20 octubre 2026, 05:10 US/Pacific (13:10 BST), los clientes que utilizan los servicios de Google Cloud Platform en la región europe-oeste2 experimentaron interrupciones de servicio en dos fases consecutivas, lo que duró un total de 6 horas, 10 minutos. Durante la fase inicial de 23:00 a 04:29 US/Pacific (07:00 a 12:29 BST) (duración 5 horas, 29 minutos), los clientes experimentaron tasas de error elevadas, tiempo de API y retrasos de procesamiento hasta que se recuperaron la mayoría de los servicios de Google Cloud Platform. Tras la restauración del servicio de plataforma, algunas cargas de trabajo de los clientes que se ejecutan en las instancias de Compute Engine experimentaron una cola de recuperación más larga. Para 04:46 US/Pacific (12:46 BST) se reanudó la creación de la máquina virtual y para 05:10 US/Pacific (13:10 BST) más del 99% de las máquinas virtuales de Motor de Computación estaban en un estado saludable. Cualquier cliente que estuviera experimentando problemas de Virtual Machine fue dirigido a presentar un problema de soporte al cliente según procedimiento normal. Si bien el desembolso de energía física se aisló estrictamente a las instalaciones de centros de datos en europe-west2-b, algunos clientes que ejecutan cargas de trabajo en zonas sin impacto (europe-west2-a y europe-west2-c) o a través de arquitecturas regionales también experimentaron impactos inesperados. Las causas primarias fueron 1\) aumentos instantáneos de la demanda en la capacidad de cálculo no probada y 2\) dependencias de validación de planos de control sincronizados a través de los límites zonales. Productos afectados incluidos: BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Regional Persistent Disk, y Cloud SQL. Estos servicios experimentaron problemas inesperados de degradación y fracaso impulsados por el agotamiento repentino de la capacidad de cálculo de la demanda, y los timeouts de API de plan de control esperando validaciones de la zona offline. Las cargas de trabajo y los recursos acogidos enteramente dentro de europe-west2-b se hicieron inalcanzables. Los servicios de almacenamiento de datos con capacidad de failover como Cloud SQL, AlloyDB, Memorystore for Redis y Cloud Bigtable fallaron en zonas cercanas sin impacto durante la salida europe-west2-b. Los servicios multizonales y regionales que abarcaban la región del europe-oeste2 experimentaron errores de latencia elevada, errores de API transitorios (como errores HTTP 500 y 503), y la admisión de tareas que se desconcentró en los recursos regionales no afectados y llamadas a componentes fuera de línea. Las operaciones de escritura de almacenamiento en la región experimentaron una tasa de error transitoria durante el período inicial de la fragilidad, y las colas de admisión de consultas regionales se elevaron temporalmente antes de subvencionarse rápidamente a medida que se reequilibraba la capacidad. Los siguientes servicios de Google Cloud Platform experimentaron impacto: * AleaciónDB para PostgreSQL * Apigee * Servicio de transferencia de datos de BigQuery * Fusión de datos en la nube * Cloud Filestore * Cloud Firestore * Equilibración de carga en la nube * Cloud Memorystore * Cloud NAT * Cloud Run * Cloud Spanner * Cloud Workstations * Datastream * Dialogflow CX * Google App Engine * Google BigQuery * Google Cloud Bigtable * Google Cloud Dataflow * Google Cloud Dataproc * Google Cloud NetApp Volumes * Google Cloud Pub/Sub * Google Cloud SQL * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Google SecOps (Información de seguridad y gestión de eventos \[SIEM\] y Orquestación de seguridad, automatización y respuesta \[SOAR\]) * Looker (Google Cloud core) * Looker Studio * Managed Airflow (Google Cloud Composer) * Servicio gestionado para Apache Kafka * Memorystore for Memcached * Memorystore for Redis * Memorystore for Redis Cluster * Memorystore for Valkey * Centro de conectividad de red * Disco persistente * Private Service Connect * Speech to-Text * Virtual Private Cloud (VPC) * Motor VMWare

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de octubre de 2026 a las 18:24 UTCresolved

   **Summary** Los clientes de Google Cloud Storage están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura **Descripción** Estamos experimentando un problema con Google Cloud Storage a partir del jueves, 2026-10-08 05:19 PDT. Nuestro equipo de ingeniería continúa investigando el tema. Ofrecemos una actualización para el jueves, 2026-10-08 11:50 PDT con los detalles actuales. **Síntomas del cliente** * Los clientes están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura. * Un subconjunto menor de operaciones de lectura también puede experimentar mayor latencia y errores *Trabajando* Nada en este momento.

2. 8 de octubre de 2026 a las 18:34 UTCresolved

   **Summary** Los clientes de Google Cloud Storage están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura **Descripción** Estamos experimentando un problema con Google Cloud Storage a partir del jueves, 2026-10-08 05:19 PDT. Mitigaciones iniciales aplicadas por nuestro equipo de ingeniería que conducen a mejoras observables en las tasas de error en nuestro monitoreo interno. Se sigue trabajando para lograr nuevas atenuaciones. Ofrecemos una actualización para el jueves, 2026-10-08 12:00 PDT con los detalles actuales. **Síntomas del cliente** * Los clientes están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura. * Un subconjunto menor de operaciones de lectura también puede experimentar mayor latencia y errores *Trabajando* Nada en este momento.

3. 8 de octubre de 2026 a las 18:55 UTCresolved

   **Summary** Los clientes de Google Cloud Storage están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura **Descripción** Estamos experimentando un problema con Google Cloud Storage a partir del jueves, 2026-10-08 05:19 PDT. Mitigaciones iniciales aplicadas por nuestro equipo de ingeniería que conducen a mejoras observables en las tasas de error en nuestro monitoreo interno a partir de las 10:57 PDT. Se sigue trabajando para lograr nuevas atenuaciones. Ofrecemos una actualización para el jueves, 2026-10-08 12:45 PDT con los detalles actuales. **Síntomas del cliente** * Los clientes están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura. * Un subconjunto menor de operaciones de lectura también puede experimentar mayor latencia y errores *Trabajando* Nada en este momento.

4. 8 de octubre de 2026 a las 19:38 UTCresolved

   **Summary** Los clientes de Google Cloud Storage están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura **Descripción** Continuamos aminorando el problema con Google Cloud Storage en la región nosotros-central1 que comenzó el jueves, 2026-10-08 05:19 PDT. Las mitigacións iniciales aplicadas por nuestro equipo de ingeniería siguen mostrando mejoras observables en las tasas de error. Nuestro equipo de ingeniería está monitoreando activamente el medio ambiente y realizando nuevas mitigacións para estabilizar plenamente el servicio. Ofrecemos una actualización para el jueves, 2026-10-08 14:00 PDT con los detalles actuales. **Síntomas del cliente** * Los clientes están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura. * Un subconjunto menor de operaciones de lectura también puede experimentar mayor latencia y errores *Trabajando* Nada en este momento.

5. 8 de octubre de 2026 a las 20:48 UTCresolved

   **Summary** Los clientes de Google Cloud Storage están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura **Descripción** Continuamos aminorando el problema con Google Cloud Storage en la región nosotros-central1 que comenzó el jueves, 2026-10-08 05:19 PDT. Las mitigacións iniciales aplicadas por nuestro equipo de ingeniería siguen mostrando mejoras observables en las tasas de error. Nuestro equipo de ingeniería está monitoreando activamente el medio ambiente y realizando nuevas mitigacións para estabilizar plenamente el servicio. Ofrecemos una actualización para el jueves, 2026-10-08 16:00 PDT con los detalles actuales. **Síntomas del cliente** * Los clientes están experimentando altas demoras y tasas de error al realizar operaciones de carga o escritura. * Un subconjunto menor de operaciones de lectura también puede experimentar mayor latencia y errores *Trabajando* Nada en este momento.

6. 9 de octubre de 2026 a las 16:44 UTCresolved

   ## Preliminary Incident Report Sinceramente nos disculpamos por la interrupción de este incidente causado a su negocio. Sabemos cuánto confías en Google Cloud y lamentamos el impacto en tu productividad. Estamos trabajando para abordar la causa raíz y evitar que esto ocurra en el futuro. Tenga en cuenta que esta información se basa en nuestro mejor conocimiento en el momento de la publicación y está sujeta a cambios a medida que continúa nuestra investigación. Un informe final de incidentes con acciones preventivas será publicado una vez que nuestra investigación esté completa. Si usted ha experimentado un impacto fuera de lo que se enumera a continuación, por favor diríjase a Google Cloud Support utilizando [https\://cloud.google.com/support](https://cloud.google.com/support) ## Date/Time of the Issue (All time US/Pacific) Incident Start: 08 October 2026 04:00 Incident End: 08 octubre 2026 16:30 Duración: 12 horas, 30 minutos ## Summary El jueves 08 de octubre de 2026, Google Cloud Storage experimentó una elevada latencia de escritura y escribió tasas de error en la región us-central1 por una duración de 12 horas, 30 minutos. Estamos tomando medidas inmediatas para asegurar que esto no vuelva a suceder. ## Preliminary Root Cause Google Cloud Storage se basa en una arquitectura de backend altamente distribuida para procesar y almacenar datos entrantes. Durante la ventana del incidente, los nodos específicos de almacenamiento de backend dentro de la región us-central1 experimentaron un déficit de capacidad localizada. La secuencia de eventos que llevaron al impacto del cliente fue la siguiente: * Una optimización de la clasificación de tráfico destinada a hacer frente a las limitaciones de capacidad localizadas causó un agotamiento severo de los recursos en los nodos específicos de almacenamiento de backend en la región afectada. * Este agotamiento de los recursos causó la ingestión de datos de objetos de backend para comenzar el tiempo fuera. * Como resultado, las solicitudes entrantes de carga y escritura enrutadas a estos nodos experimentaron latencia elevada y no se completaron, lo que dio lugar a errores en superficie a los clientes. * Concurrently, a separate issue with the underlying database service contributed to additional metadata processing errors during a portion of the incident window. Los ingenieros de Google han iniciado un análisis completo de causa raíz (RCA) y proporcionarán información adicional una vez que esté disponible. ## Remediation El problema fue detectado inicialmente por los equipos de ingeniería de Google monitoreando activamente la telemetría del sistema temprano en la ventana del incidente. Para mitigar el problema, los ingenieros de Google ejecutaron la siguiente estrategia paso a paso: * Inicialmente, los ingenieros intentaron asignar dinámicamente capacidad de emergencia adicional a la región afectada, pero esto se vio bloqueado por límites sistémicos de capacidad regional. * Para aliviar la presión inmediata, los ingenieros disminuían selectivamente el tráfico de los nodos de almacenamiento de backend más sobrecargados. * Se desplegó un cambio de configuración para desactivar la optimización de clasificación de tráfico, reduciendo significativamente la sobrecarga de recursos en el backend de almacenamiento. * Para la cuestión concurrente de metadatos, los ingenieros hicieron una actualización reciente del servicio de base de datos de metadatos subyacentes. Una vez estabilizados los niveles de tráfico y la utilización de los recursos se devolvió a niveles normales de referencia, los nodos previamente drenados fueron restaurados al servicio activo, restaurando con éxito las operaciones normales. ## Descripción del impacto El 08 de octubre, 2026, de 04:00 a 16:30 US/Pacific, los clientes que utilizan la región us-central1 experimentaron altas tasas de latencia y errores durante las operaciones de carga y escritura de Cloud Storage. * Los clientes observaron principalmente errores HTTP 503 UNAVAILABLEs en operaciones de WriteObject y timeouts cliente-side. * También se observó un menor impacto en las operaciones de lectura durante este período. * Las operaciones de almacenamiento en la nube en todas las demás regiones, así como todos los demás servicios de Google Cloud, no se vieron afectadas por este evento específico.

7. 14 de octubre de 2026 a las 7:15 UTCresolved

   ## Incident Report ## Date/Time of the Issue (All time US/Pacific) **Primero incidente* Incident Start: 08 October 2026 04:00 Incident End: 08 octubre 2026 16:30 Duración: 12 horas, 30 minutos **Recurrencia accidental** Recurrencia Inicio: 09 Octubre 2026 04:05 Recurrencia final: 09 octubre 2026 09:46 Duración: 5 horas, 41 minutos **Duración total:** 18 horas, 11 minutos ## Summary El jueves 08 de octubre de 2026, Google Cloud Storage experimentó una elevada latencia de escritura y escribió tasas de error mientras realizaba operaciones de carga o escritura en la región us-central1 durante una duración de 12 horas, 30 minutos. Esto fue seguido por una recurrencia el viernes, 09 de octubre de 2026 en la zona nosotros-central1-b por una duración de 5 horas, 41 minutos. Estamos tomando medidas inmediatas para asegurar que esto no vuelva a suceder. ## Root Cause Google Cloud Storage se basa en una arquitectura de backend altamente distribuida para procesar y almacenar datos entrantes. Durante la ventana del incidente, los nodos específicos de almacenamiento de backend dentro de la región us-central1 experimentaron un déficit de capacidad localizado debido al aumento del tráfico. La secuencia de eventos que llevaron al impacto del cliente fue la siguiente: * Una actualización de configuración de optimización de clasificación de tráfico a la capa de equilibrio de carga de Google Cloud Storage destinada a abordar las limitaciones de capacidad localizadas causó un agotamiento severo de los recursos en los nodos de almacenamiento específicos en la región afectada al pasar inadvertidamente la lógica de enrutamiento de capacidad estándar, lo que dio lugar a un desequilibrio de carga severo. * En consecuencia, una pequeña fracción de los nodos de backend de almacenamiento en la región us-central1 recibió una proporción abrumadora de tráfico de escritura entrante a pesar de tener baja capacidad de servicio disponible. Esta concentración de tráfico llevó al agotamiento de los recursos en los servidores de backend afectados que causaron la ingestión de los datos de objetos de backend para comenzar el tiempo fuera. * Debido a que las instancias subyacentes no podían procesar el alto volumen de solicitudes lo suficientemente rápido, las solicitudes entrantes de carga y escritura se encaminaron a estos nodos experimentaron latencia elevada y no terminaron, lo que dio lugar a errores en la superficie de los clientes. * Concurrently, a separate issue with the underlying database service contributed to additional metadata processing errors during a portion of the incident window. * La recurrencia del tema el 9 de octubre fue causada por un rebote incompleto de una función de planificador de carga, que rompió el mecanismo de equilibrio de carga y sobrecarga unos pocos nodos de almacenamiento más pequeños. ## Remediation and Prevention El problema fue detectado inicialmente el 08 de octubre de 2026 a las 04:50 por los equipos de ingeniería de Google monitoreando activamente la telemetría del sistema temprano en la ventana del incidente. Para mitigar el problema, los ingenieros de Google ejecutaron la siguiente estrategia paso a paso: * Inicialmente, los ingenieros intentaron asignar dinámicamente capacidad de emergencia adicional a la región afectada, pero esto se vio bloqueado por límites sistémicos de capacidad regional. * Para aliviar la presión inmediata, los ingenieros disminuían selectivamente el tráfico de los nodos de backend de almacenamiento más sobrecargados. * Se desplegó un cambio de configuración para desactivar la optimización de clasificación de tráfico, reduciendo significativamente la sobrecarga de recursos en el backend de almacenamiento. * Para la cuestión concurrente de metadatos, los ingenieros hicieron una actualización reciente del servicio de base de datos de metadatos subyacentes. * Si bien estos pasos proporcionaron alivio temporal, una repetición del desequilibrio de carga requería mayor redireccion y drenaje de los componentes de almacenamiento afectados. El incidente se resolvió permanentemente cuando la ingeniería revertía completamente el cambio de configuración de equilibrio de carga problemático, restaurando el comportamiento anterior de enrutamiento de capacidad y permitiendo que el tráfico distribuyera uniformemente en toda la región. Una vez estabilizados los niveles de tráfico y la utilización de los recursos se devolvió a niveles normales de referencia, los nodos previamente drenados fueron restaurados al servicio activo, restaurando con éxito las operaciones normales. ** Acciones preventivas:** Para asegurar que esta cuestión no se repita, estamos implementando las siguientes mejoras: * Rollouts de configuración de seguridad* Estamos actualizando nuestros protocolos de despliegue para asegurar que los cambios de lógica de equilibrio de carga se validen rigurosamente en regiones alternativas y más pequeñas antes de ser lanzados a regiones más grandes y altamente utilizadas. *Controles operativos inteligentes* Estamos mejorando la arquitectura de equilibrio de carga de almacenamiento para hacer cumplir estrictamente las limitaciones de capacidad, asegurando que la lógica de distribución de tráfico no pueda evitar las salvaguardias previas al almacenamiento y el tráfico de rutas a grupos que carecen de suficientes recursos de servicio. - **Resilient Scaling Logic:** Estamos implementando mejoras específicas para acelerar el movimiento de datos internos dentro de células de almacenamiento altamente utilizadas, permitiendo al sistema procesar datos de manera más eficiente y manejar picos de carga temporales con mayor resiliencia. ## Descripción del impacto On 08 October 2026, from 04:00 to 16:30 in us-central1 region and 09 October 2026, from 04:05 to 09:46 in us-central1-b zone, customers experienced higherted latency and error rates during Cloud Storage upload and write operations. * **Upload & Write Failures:** Los clientes observaron principalmente errores HTTP 503 UNAVAILABLEs en operaciones de WriteObject y timeouts lado cliente. * **Increased Write Latency:** Escribir operaciones que tuvieron éxito experimentó un retraso significativamente mayor de lo normal. * Las operaciones de almacenamiento en la nube en todas las demás regiones, así como todos los demás servicios de Google Cloud, no se vieron afectadas por este evento específico.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de septiembre de 2026 a las 16:03 UTCresolved

   **Summary** Múltiples productos en nosotros-central1-b están experimentando la degradación del servicio de red. **Descripción** Estamos experimentando un problema de networking a partir del martes, 2026-09-01 07:41 US/Pacific. La cuestión está afectando una parte de la zona central-b. Las zonas restantes de la región no están afectadas. Nuestro equipo de ingeniería de red ha puesto en mitigación y estamos viendo servicios empezando a recuperarse. Ofrecemos más información para el martes, 2026-09-01 09:30 US/Pacific con detalles actuales. Nos disculpamos con todos los afectados por la perturbación. **Síntomas del cliente** Los clientes están experimentando pérdidas elevadas de paquetes y errores. * BigQuery * Flujo de datos en la nube * Cloud SQL * App Engine * Cloud Run * AlloyDB * Cloud Bigtable * Cloud Spanner * Motor de Computación * Cloud VPN * Cloud Interconnect * Cloud NAT * Cloud Filestore * Conectividad híbrida en la nube * Virtual Private Cloud * Google Kubernetes Engine * Looker (Google Cloud core) *Trabajando* * Los clientes con retries de capa de servicio pueden ver terminaciones exitosas ya que sólo una parte de la zona se ve afectada. * Los clientes que se ven gravemente afectados y tienen servicios disponibles en zonas alternas pueden fallar en zonas alternadas.

2. 1 de septiembre de 2026 a las 16:19 UTCresolved

   **Summary** Múltiples productos en nosotros-central1-b están experimentando la degradación del servicio de red. **Descripción** La cuestión está afectando una parte de la zona central-b. Las zonas restantes de la región no están afectadas. Tras los esfuerzos de mitigación a nivel de red, la infraestructura de red subyacente se ha recuperado plenamente. Los equipos de ingeniería de productos de Cloud están validando el estado de recuperación de los servicios individuales. Ofrecemos más información para el martes, 2026-09-01 10:00 US/Pacific con detalles actuales. **Síntomas del cliente** Los clientes están experimentando pérdidas elevadas de paquetes y errores. * BigQuery * Flujo de datos en la nube * Cloud SQL * App Engine * Cloud Run * AlloyDB * Cloud Bigtable * Cloud Spanner * Motor de Computación * Cloud VPN * Cloud Interconnect * Cloud NAT * Cloud Filestore * Conectividad híbrida en la nube * Virtual Private Cloud * Google Kubernetes Engine * Looker (Google Cloud core) * Apigee * Google SecOps SOAR *Trabajando* * Los clientes con retries de capa de servicio pueden ver terminaciones exitosas ya que sólo una parte de la zona se ve afectada. * Los clientes que se ven gravemente afectados y tienen servicios disponibles en zonas alternas pueden fallar en zonas alternadas.

3. 1 de septiembre de 2026 a las 17:09 UTCresolved

   **Summary** Múltiples productos en nosotros-central1-b están experimentando la degradación del servicio de red. **Descripción** La cuestión está afectando una parte de la zona central-b. Las zonas restantes de la región no están afectadas. La mayoría de los productos se han recuperado y el equipo de ingeniería sigue validando algunos impactos de productos restantes. Ofrecemos más información para el martes, 2026-09-01 11:00 US/Pacific con detalles actuales. **Síntomas del cliente** Los clientes están experimentando pérdidas elevadas de paquetes y errores. * Cloud Run * App Engine Los productos se han recuperado * BigQuery * Flujo de datos en la nube * Cloud Bigtable * Motor de Computación * Conectividad híbrida en la nube * Cloud Filestore * Virtual Private Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud Interconnect * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firestore *Trabajando* * Los clientes con retries de capa de servicio pueden ver terminaciones exitosas ya que sólo una parte de la zona se ve afectada. * Los clientes que se ven gravemente afectados y tienen servicios disponibles en zonas alternas pueden fallar en zonas alternadas.

4. 1 de septiembre de 2026 a las 18:01 UTCresolved

   **Summary** Múltiples productos en nosotros-central1-b están experimentando la degradación del servicio de red. **Descripción** La cuestión está afectando una parte de la zona central-b. Las zonas restantes de la región no están afectadas. La mayoría de los productos se han recuperado y el equipo de ingeniería sigue validando algunos impactos de productos restantes. El mantenimiento de la red de rutina provocó problemas en nosotros-central1-b. Hemos recuperado la capacidad de red que fue impactada y restaurada todos los servicios zonales y regionales. El mantenimiento en la región se ha detenido mientras se realizan auditorías proactivas. Ofrecemos más información para el martes, 2026-09-01 12:30 US/Pacific con detalles actuales. **Síntomas del cliente** Los clientes están experimentando pérdidas elevadas de paquetes y errores. * Cloud Run * App Engine Los productos se han recuperado * BigQuery * Flujo de datos en la nube * Cloud Bigtable * Motor de Computación * Conectividad híbrida en la nube * Cloud Filestore * Virtual Private Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud Interconnect * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firestore *Trabajando* * Los clientes con retries de capa de servicio pueden ver terminaciones exitosas ya que sólo una parte de la zona se ve afectada.

5. 1 de septiembre de 2026 a las 18:36 UTCresolved

   **Summary** Múltiples productos en nosotros-central1-b están experimentando la degradación del servicio de red. **Descripción** La cuestión está afectando una parte de la zona central-b. Las zonas restantes de la región no están afectadas. La mayoría de los productos se han recuperado. Los productos impactados Cloud Run y App Engine también están viendo la recuperación y los errores han reducido los niveles de preincidencia. La ingeniería sigue monitoreando y validando. El mantenimiento de la ruta de la red de rutina provocó problemas inesperados en dos grupos en nosotros-central1-b. Hemos recuperado la capacidad de red que fue impactada y restaurada todos los servicios zonales y regionales. El mantenimiento en la región se ha detenido mientras se realizan auditorías proactivas. Ofrecemos más información para el martes, 2026-09-01 12:30 US/Pacific con detalles actuales. **Síntomas del cliente** Los clientes están experimentando pérdidas elevadas de paquetes y errores. * Cloud Run * App Engine Los productos se han recuperado * BigQuery * Flujo de datos en la nube * Cloud Bigtable * Motor de Computación * Conectividad híbrida en la nube * Cloud Filestore * Virtual Private Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud Interconnect * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firestore *Trabajando* * Los clientes con retries de capa de servicio pueden ver terminaciones exitosas ya que sólo una parte de la zona se ve afectada.

6. 1 de septiembre de 2026 a las 19:12 UTCresolved

   **Summary** Múltiples productos en la degradación de servicios de red con experiencia de us-central1. **Descripción** La cuestión estaba afectando una parte de la zona central-b. Las zonas restantes de la región no se vieron afectadas. Todos los productos impactados se han recuperado. Desde el análisis preliminar, el mantenimiento rutinario de la ruta del tejido de red provocó problemas inesperados en un grupo en nosotros-central1-b. Hemos recuperado la capacidad de red que fue impactada y restaurada todos los servicios zonales y regionales. El mantenimiento en la región se ha detenido mientras se realizan auditorías proactivas. Le agradecemos su paciencia mientras trabajamos para resolver el problema. **Síntomas del cliente** Los clientes experimentaron una elevada pérdida de paquetes y errores. *Trabajando* La cuestión ha sido mitigada.

7. 3 de septiembre de 2026 a las 17:47 UTCresolved

   ## Preliminary Incident Report Sinceramente nos disculpamos por la interrupción de este incidente causado a su negocio. Sabemos cuánto confías en Google Cloud y lamentamos el impacto en tu entorno. Estamos trabajando para abordar la causa raíz y evitar que esto ocurra en el futuro. Tenga en cuenta que esta información se basa en nuestro mejor conocimiento en el momento de la publicación y está sujeta a cambios a medida que continúa nuestra investigación. Un informe final de incidentes con acciones preventivas será publicado una vez que nuestra investigación esté completa. Si usted ha experimentado impacto fuera de lo que se enumera a continuación, por favor contacte a Google Cloud Support utilizando https://cloud.google.com/support ## Date/Time of the Issue (All time US/Pacific) **Incident Start**: 1 septiembre 2026 07:41 **Incident End**: 1 de septiembre de 2026 11:52 **Duración**: 4 horas, 11 minutos ## Summary El martes 1 de septiembre de 2026, algunos clientes de nosotros-central1-b experimentaron la degradación de los servicios de red y acuden al aislamiento durante 4 horas y 11 minutos. A nuestros clientes cuyas empresas fueron impactadas durante esta perturbación, nos disculpamos sinceramente. Este no es el nivel de calidad y fiabilidad que nos esforzamos para ofrecerle, y estamos tomando medidas inmediatas para mejorar el rendimiento y la disponibilidad de la plataforma. ## Preliminary Root Cause El desencadenante técnico inmediato para este evento fue la desconexión física inadvertida de cables de fibra óptica de red durante un procedimiento de mantenimiento de hardware de rutina. Un ingeniero estaba realizando una mejora de la capacidad programada en los routers de centro de datos que soportan una fracción de capacidad en la zona us-central1-b. La arquitectura de red para cada centro de datos está diseñada con redundancia en múltiples dispositivos de enrutamiento. El sistema está diseñado para ser resistente a todas las fallas de un solo dispositivo o de una vía de fibra, y la mayoría de las fallas dobles o triples no afectan el tráfico de clientes. Para asegurar esto, los dispositivos y las vías de fibra están físicamente separados en cada centro de datos, con diversas fuentes de energía. Un error procesal significaba que la acción de mantenimiento físico desplegó secuencialmente el 100% de las vías de fibra en todos los dispositivos dentro de 13 minutos. La naturaleza del error, combinado con la velocidad de la acción, impidió advertencias de acción incorrecta que llegaran al ingeniero antes de la desconexión completa. Esto dio lugar a que la capacidad de cálculo de la zona afectada estuviera aislada de la red. Los clientes no pudieron llegar a sus máquinas virtuales, y esas máquinas virtuales no podían establecer conexiones fuera de su zona. ## Remediation La cuestión fue detectada inmediatamente por sistemas automatizados de monitoreo de pérdidas de red y sondas proactivas, que rápidamente contrató a los equipos de ingeniería de red y respuesta a incidentes. Para mitigar el impacto inmediato de los clientes, los equipos de ingeniería desplazaron activamente el tráfico de la infraestructura afectada, desplazando automáticamente el tráfico de carga de trabajo compatible a una capacidad saludable en otros lugares de la región. Concurrentemente, los técnicos de operaciones de hardware en el sitio identificaron los enlaces ópticos desconectados y researon físicamente las fibras. Una vez restaurados los enlaces físicos, se normalizaron los flujos de tráfico y el tráfico fue redirigido de nuevo para devolver la capacidad de servicio. ## Descripción del impacto El martes 1 de septiembre, de 07:41 a 11:52 Estados Unidos/Pacífico, una parte de la zona central1-b experimentó una grave degradación de la red y aislamiento de recursos. * **Productos básicos afectados:** La interrupción de la red a / desde una parte de nosotros-central1-b impactó múltiples productos GCP para algunos clientes en esa zona. * **Error rate:** Las tasas de caída del flujo de tráfico para los recursos alojados en la zona afectada alcanzaron el 100% durante el pico del incidente, lo que dio lugar a máquinas virtuales inalcanzables y una elevada pérdida de paquetes. ** Servicios y características afectados** * **Google Compute Engine:** Incapacidad de acceder a máquinas virtuales externamente, e incapacidad para los VMs para alcanzar recursos remotos. * **Google Kubernetes Engine:** Unreachable regional/zonal clusters and nodes within the affected zone, prompting delay cluster recovery times. * **Cloud Run / Google App Engine:** Los picos temporales de latencia y los abortos pendientes de cola como cargas de trabajo de backend evacuaron automáticamente y cambiaron a una capacidad saludable. Un subconjunto de cargas de trabajo en la zona especialmente afectada experimentó degradación hasta las 11:52 Estados Unidos/Pacífico. * **Cloud SQL, AlloyDB for PostgreSQL, Cloud Spanner, Google Cloud Bigtable, Cloud Filestore:** El acceso a los datos y la conectividad se redujeron para casos localizados estrictamente a la infraestructura afectada. * **Virtual Private Cloud (VPC), Cloud NAT, Apigee, Google BigQuery, Google Cloud Dataflow, Looker, Google SecOps SOAR, Hybrid Connectivity, Cloud Interconnect:** Pérdida de paquetes de red elevada, gotas de conectividad y timeouts de API en la zona afectada.

8. 10 de septiembre de 2026 a las 21:20 UTCresolved

   ## Incident Report ## Summary El martes 1 de septiembre de 2026, algunos clientes de nosotros-central1 experimentaron la degradación de los servicios de red y acuden al aislamiento durante 4 horas y 11 minutos. A nuestros clientes cuyas empresas fueron impactadas durante esta perturbación, nos disculpamos sinceramente. Este no es el nivel de calidad y fiabilidad que nos esforzamos para ofrecerle, y estamos tomando medidas inmediatas para mejorar el rendimiento y la disponibilidad de la plataforma. ## Root Cause El evento fue desencadenado por la desconexión física inadvertida de cables de fibra óptica de red durante el mantenimiento de hardware rutinario. Un técnico estaba realizando una actualización de capacidad programada en los routers del centro de datos que soportan una fracción de capacidad en la zona us-central1-b y una pequeña fracción de capacidad en la zona us-central1-f. Durante el mantenimiento práctico, las fibras ópticas que conectan los routers del centro de datos a la tela de red fueron desplegadas y los transceptores ópticos fueron reemplazados por un transceptor que soporta conectividad de densidad superior. Este transceptor no era compatible con los transceptores que aún existían en el tejido del centro de datos, causando una pérdida de conectividad para cada fibra. La red está diseñada con routers redundantes en salas separadas del centro de datos dentro del mismo edificio para que el fracaso de un router no interrumpa el servicio. El mantenimiento estaba destinado a actualizar un router a la vez durante varios días, con desvíos de tráfico a cada paso y verificación entre pasos que la red ha retornado a un estado totalmente conectado. Sin embargo, un error de procedimiento en el proceso de actualización manualmente orquestado causó la lista completa de reemplazos de transceptores en todos los routers que se emitirán al técnico sin instrucciones para secuenciar el trabajo un router a la vez. El flujo de trabajo de mantenimiento tampoco incluyó las medidas de verificación humana y de software previstas para detectar trastornos no deseados. Como resultado, el técnico desplegó secuencialmente todas las vías de fibra a través de los dispositivos afectados dentro de 13 minutos. La velocidad y la naturaleza del error impidió que las advertencias de acción incorrecta llegar al ingeniero antes de perder la conectividad. Además, no se siguió un procedimiento permanente para detener si se detecta luz en cualquier cable de fibra óptica después de desconectar. Esto dio lugar a que la capacidad de cálculo de la zona afectada estuviera aislada de la red. Los clientes no pudieron llegar a sus máquinas virtuales, y esas máquinas virtuales no podían establecer conexiones fuera de su zona. ## Remediation and Prevention La cuestión fue detectada inmediatamente por sistemas automatizados de monitoreo de pérdidas de red y sondas proactivas, que rápidamente contrató a los equipos de ingeniería de red y respuesta a incidentes. Para mitigar el impacto inmediato del cliente, los equipos de ingeniería desplazaron activamente el tráfico de la infraestructura afectada. Concurrentemente, técnicos de operaciones de hardware en el sitio identificaron los enlaces ópticos desconectados y re-inserted físicamente los transceptores ópticos originales. Una vez restaurados los enlaces físicos, se normalizaron los flujos de tráfico y el tráfico fue redirigido de nuevo para devolver la capacidad de servicio. Google se compromete a prevenir una repetición de esta cuestión en el futuro y está completando las siguientes acciones: * Reforzar el entrenamiento en la región central y globalmente alrededor de técnicas de mantenimiento seguras, incluyendo el requisito obligatorio de verificar si la luz está en cada fibra sin mancha. * Terminar la migración de flujos de trabajo de actualización de red a un sistema de orquestación completamente secuenciado automáticamente. La mayoría de los flujos de trabajo regionales comunes se completaron en 2025, y se están realizando corrientes de trabajo zonales. * Complete el despliegue de la parada de trabajo alertando por acciones que resultan en la desconexión no deseada de cables de fibra en vivo en centros de datos de Google. * Completar el despliegue del sistema automatizado que desplazará el tráfico regional lejos de las zonas defectuosas, reduciendo el tiempo de aproximadamente 19 minutos en este caso a unos 5 minutos. ## Descripción detallada del impacto El martes 1 de septiembre, de 07:41 a 11:52 EE.UU./Pacífico, una parte de las zonas us-central1-b y us-central1-f experimentaron una grave degradación de la red y aislamiento de recursos. 1. Múltiples productos afectados: La interrupción de la red a/desde una porción de zonas us-central1-b y us-central1-f impactó a todos los productos GCP zonales para algunos clientes en esas zonas. 2. Impacto regional: Los productos regionales que utilizan la capacidad en el centro de datos afectados se vieron afectados hasta que las desviaciones de tráfico se efectuaron plenamente a las 08:00. Google Kubernetes Motor y Cloud Run / Google App Engine tuvo impactos más largos, discutidos a continuación. 3. Tasa de error: Las tasas de caída del flujo de tráfico para los recursos alojados en la zona afectada alcanzaron el 100% durante el pico del incidente, lo que dio lugar a máquinas virtuales inalcanzables y una elevada pérdida de paquetes. ** Servicios y características afectados** * Google Compute Engine: Inability for users in the affected portion of us-central1-b and us-central1-f zones to access virtual machines externally, and inability for VMs to reach remote resources. * Cloud SQL, AlloyDB for PostgreSQL, Google Cloud Bigtable, Cloud Filestore: El acceso a los datos y la conectividad se redujeron para casos localizados estrictamente a la infraestructura impactada. * Cloud Spanner, Cloud Firestore: Elevated Remote Procedure Call (RPC) tasas de error, tiempo de escritura, y picos de latencia para las instancias de multiregión nam5 debido a la conectividad cortada a los componentes que se ejecutan en la zona afectada. * Virtual Private Cloud (VPC), Cloud NAT, Apigee, Google BigQuery, Google Cloud Dataflow, Looker, Google SecOps SOAR, Hybrid Connectivity, Cloud Interconnect: Elevated network packet loss, connectivity drops, and API timeouts in the impacted zone. * Google Kubernetes Engine (GKE): Entre 07:40 y 09:15 US/Pacific on 2026-09-01, los clientes experimentaron errores y timeouts en solicitudes a sus aviones de control de agrupaciones GKE (Kubernetes API servers) en nosotros-central1. Esto podría haber causado que las cargas de trabajo nuevas o actualizadas fallaran en la programación y las operaciones de la API de Kubernetes fracasaran. * Cloud Run / Google App Engine: Los picos temporales de latencia y las colas pendientes abortan como las cargas de trabajo de backend evacuaron y cambiaron a una capacidad saludable. Un subconjunto de cargas de trabajo en la zona especialmente afectada experimentó degradación hasta las 11:52 Estados Unidos/Pacífico. ** Impacto del cliente** Los clientes con recursos alojados en los grupos afectados específicos dentro de nosotros-central1-b y nosotros-central1-f experimentaron una pérdida completa de conectividad de red a partir de las 07:41 US/Pacific. Durante este tiempo, máquinas virtuales y servicios asociados se hicieron inalcanzables desde internet y desde otras regiones de Google Cloud, y esos recursos internos no podían iniciar conexiones externas. El problema fue detectado casi inmediatamente y los ingenieros tomaron acciones de desviación de tráfico a las 07:45 y 08:00 US/Pacific para reducir el impacto a los productos regionales. Para 08:50 US/Pacífico, la mayoría de las conexiones físicas fueron restauradas y el tráfico comenzó a recuperarse, y las acciones de desvío de tráfico fueron eliminadas a las 09:19 US/Pacífico. La recuperación total en casi todos los servicios afectados y las operaciones de larga duración fue confirmada por 11:52 Estados Unidos/Pacífico. Debido a que el aislamiento de la red se limitó estrictamente a grupos específicos dentro de nosotros-central1-b y nosotros-central1-f, las implementaciones multi-zona utilizando correctamente la redundancia en otras zonas en nosotros-central1 fueron en gran medida capaces de evitar la falla del hardware físico y continuar sirviendo tráfico. Los clientes con proyectos tanto en nosotros-central1-b como en nosotros-central1-f no habrían visto impacto multi-zona - en la mayoría de sus zonas tendrían capacidad en el centro de datos afectado.

9. 29 de septiembre de 2026 a las 16:09 UTCresolved

   ## Addendum to Incident Report Esta adición extiende la descripción detallada del impacto desde el mensaje anterior. Aunque sólo dos grupos en un centro de datos en el aislamiento de red con nosotros-central1-b y nosotros-central1-f experimentados, algunos productos regionales con dependencia del centro de datos afectados también fueron afectados. Entre 07:41 y 11:52 Estados Unidos/Pacífico el martes 1 de septiembre de 2026, los siguientes productos fueron afectados: - **Compute Engine VMs**: VMs corriendo en el centro de datos afectado perdió conectividad de red a recursos situados fuera de su centro de datos. Desde la perspectiva de Compute Engine, este incidente sólo afectó un subconjunto de VMs en nosotros-central1-b y nosotros-central1-f. - **Productos Zoológicos y Regionales basados en el Motor de Computación** Productos con dependencia de VMs en el centro de datos afectado experimentaron síntomas como timeouts de conexión o falta de servicio porque los VM subyacentes perdieron conectividad de red. Ejemplos de productos que se basan en VMs de Motor Compute incluyen: Apigee, Cloud SQL, AlloyDB para PostgreSQL, Dataflow, Cloud Filestore y Looker. - **Google Kubernetes Engine (GKE)**: GKE clusters cuyo plano de control tenía dependencias en los equipos de control VM de los grupos afectados experimentaron errores y timeouts cuando administradores o nodos intentaron conectarse al servidor de la API de Kubernetes. En consecuencia, los despliegues podrían haberse retrasado, las operaciones de la API de Kubernetes podrían haber fracasado, y los nuevos nodos podrían no haberse registrado en el plano de control (causando retrasos operacionales de la piscina de nodos). - **Cloud Run and App Engine:** Las cargas de trabajo en la región us-central1 experimentaron latencia elevada de servicio, errores de solicitud abortados de 5xx y degradación de conectividad externa. Para evitar fallos de solicitud graves, el tráfico se desvió a otros grupos. Diverting requests to other clusters temporarily caused elevated latency or errors in those clusters. Una vez que se restableció el cluster impactado, la demanda de carga de trabajo de estos nuevos backends creó un 'rebaño de cobertura' de inicializaciones de instancias concurrentes. Esta repentina oleada superó los caches cálidos y superó los niveles internos de servicio de archivos, extendiendo los síntomas hasta que se proporcionó capacidad de emergencia. **Otros API y Servicios de Google**, en nosotros-central1 o una multiregión que incluye a nosotros-central1, se vieron afectados si tenían dependencias de tareas de software en los grupos afectados y no pudieron utilizar tareas de software en un grupo no afectado. Los síntomas incluyeron tiempo de conexión o falta de servicio. Ejemplos de otras API y servicios de Google son: Google Cloud Bigtable, BigQuery, Google SecOps SOAR, Cloud Spanner y Cloud Firestore. Para algunos servicios, los síntomas se limitaron a aumentos temporales de latencia y falta de servicio hasta que la carga de trabajo se desplazara a grupos no afectados. **Servicio privado Connect**: Los clientes (en cualquier región) experimentaron problemas de conectividad con puntos finales de PSC con dependencias en nosotros-central1, en circunstancias específicas: - Los puntos finales de PSC de Google API se vieron afectados de la misma manera que se señala en la sección de Google APIs y servicios. - Productor/consumidor Los puntos finales del PSC se vieron afectados si el productor tenía balanceadores de carga o VM de backend en los grupos afectados de nosotros-central1. - **Conectividad híbrida**: Algunos acoplamientos de Cloud Router, Cloud VPN y Cloud Interconnect VLAN en nosotros-central1 se vieron afectados en circunstancias específicas: - tareas de software Cloud Router BGP para algunos routers Cloud en nosotros-central1 experimentaron un evento de mantenimiento de Cloud Router si sus tareas de software BGP se ejecutan en los grupos afectados. - Las tareas del software de túnel VPN Cloud que se ejecutan en los grupos afectados perdieron la conectividad de red. Esto causó que algunos túneles de VPN Cloud en nosotros-central1 bajaran hasta que se asignara una tarea de túnel de reemplazo en un grupo diferente. - Los recursos (en cualquier región) enviar paquetes a través de archivos adjuntos de Cloud Interconnect VLAN en nosotros-central1 podrían haber experimentado problemas de conectividad intermitente en ciertas situaciones en las que los flujos de red ya no estaban programados. * Balanceadores de carga basados en enviados y otros productos*: Los balanceadores de carga y otros productos que dependían de las tareas de Envoy gestionadas de una subred sólo proxy en nosotros-central1 experimentaron mayores problemas de latencia o conectividad si las tareas de Envoy eran suficientes en los grupos afectados. Los siguientes productos se vieron afectados: - Balances de carga de aplicaciones externas regionales en nosotros-central1 - Balances de carga de aplicaciones internas regionales en nosotros-central1 - Balanceadores de carga de aplicaciones internas de regulación cruzada con ejes en nosotros-central1 - Equilibros de carga de red externa de proxy regional en nosotros-central1 - Equilibros de carga de red proxy interna de regulación cruzada con ejes en nosotros-central1

Traducido automáticamente desde la actualización oficial del incidente.

1. 20 de agosto de 2026 a las 16:44 UTCresolved

   **Summary** Estamos investigando un problema en el que los clientes pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos de la región us-west1. **Descripción** Estamos experimentando un problema con múltiples productos, comenzando el jueves, 2026-08-20 08:40 PDT. Nuestro equipo de ingeniería continúa investigando el tema. Ofrecemos una actualización para el jueves, 2026-08-20 10:30 PDT con detalles. Nos disculpamos con todos los afectados por la perturbación. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* Nada en este momento.

2. 20 de agosto de 2026 a las 17:13 UTCresolved

   **Summary** Estamos investigando un problema en el que los clientes pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos de la región us-west1. **Descripción** Nuestros equipos de ingeniería aplican medidas de mitigación, se han observado tendencias de recuperación en capas de infraestructura. Se siguen realizando esfuerzos activos para que los servicios de nube afectados vuelvan a funcionar plenamente. Ofrecemos una actualización para el jueves, 2026-08-20 10:45 PDT con detalles. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* Recomendamos a los clientes que fallen a otras regiones cuando sea factible.

3. 20 de agosto de 2026 a las 17:32 UTCresolved

   **Summary** Estamos investigando un problema en el que los clientes pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos de la región us-west1. **Descripción** Nuestros equipos de ingeniería aplican medidas de mitigación, se han observado tendencias de recuperación en capas de infraestructura. Se siguen realizando esfuerzos activos para que los servicios de nube afectados vuelvan a funcionar plenamente. Ofrecemos una actualización para el jueves, 2026-08-20 11:00 PDT con detalles. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* Recomendamos a los clientes que fallen a otras regiones cuando sea factible.

4. 20 de agosto de 2026 a las 18:03 UTCresolved

   **Summary** Se ha mitigado la cuestión que ocasiona tiempo, degradación, errores y retrasos en varios productos us-west1 y estamos trabajando para recuperar todos los productos. **Descripción** Las acciones de mitigación han sido completadas por nuestros equipos de ingeniería y estamos viendo la recuperación de múltiples productos. Seguimos trabajando para recuperar los productos restantes. Ofrecemos una actualización para el jueves, 2026-08-20 11:45 PDT con detalles. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* No se necesitan soluciones de trabajo en este momento.

5. 20 de agosto de 2026 a las 18:53 UTCresolved

   **Summary** Se ha mitigado la cuestión que ocasiona tiempo, degradación, errores y retrasos en varios productos us-west1 y estamos trabajando para recuperar todos los productos. **Descripción** Las acciones de mitigación han sido completadas por nuestros equipos de ingeniería y estamos viendo la recuperación de múltiples productos. Seguimos trabajando para recuperar los productos restantes. Ofrecemos una actualización para el jueves, 2026-08-20 12:30 PDT con detalles. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* No se necesitan soluciones de trabajo en este momento.

6. 20 de agosto de 2026 a las 19:21 UTCresolved

   **Summary** Se ha mitigado la cuestión que ocasiona tiempo, degradación, errores y retrasos en varios productos us-west1 y estamos trabajando para recuperar todos los productos. **Descripción** Las acciones de mitigación han sido completadas por nuestros equipos de ingeniería y estamos viendo la recuperación de múltiples productos. Seguimos trabajando para recuperar los productos restantes. Ofrecemos una actualización para el jueves, 2026-08-20 13:30 PDT con detalles. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden experimentar timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* No se necesitan soluciones de trabajo en este momento.

7. 20 de agosto de 2026 a las 19:37 UTCresolved

   **Summary** Se ha mitigado la cuestión de los plazos, las degradaciones, los errores y las demoras en varios productos us-west1. **Descripción** Hemos mitigado el tema impactando múltiples productos en nuestra región nosotros-oeste1 al jueves, 2026-08-20 10:22 PDT. Nuestros equipos de ingeniería han restaurado la capacidad en un mantenimiento óptico planificado que causó congestión inesperada en Dalles, Oregon metro /us-west1 región. Nuestros sistemas se han estabilizado y los servicios se han recuperado una vez restaurada la capacidad. Nuestros equipos siguen vigilando cualquier impacto residual. Publicaremos un análisis de este incidente una vez que hayamos completado nuestra investigación interna. Le agradecemos su paciencia mientras trabajamos para resolver el problema. **Diagnosis / Síntomas del cliente** Los clientes en nosotros-oeste1 pueden haber experimentado timeouts, degradación de los servicios, errores y retrasos elevados en varios productos. *Trabajando* Esta cuestión se ha mitigado ahora.

8. 25 de agosto de 2026 a las 6:20 UTCresolved

   Informe preliminar sobre incidentes Sinceramente nos disculpamos por la interrupción de este incidente causado a sus operaciones comerciales. Reconociendo su confianza en Google Cloud, expresamos nuestros sinceros pesares por cualquier impacto operacional experimentado. Nuestros equipos de ingeniería están abordando activamente la causa raíz subyacente para prevenir las recurrencias futuras. Tenga en cuenta que la información proporcionada refleja nuestro entendimiento actual a partir del momento de la publicación y sigue siendo objeto de revisión a medida que avanza la investigación. Al concluir nuestra investigación, se publicará un informe completo sobre los incidentes en el que se detallan las medidas preventivas. Si usted ha experimentado impacto fuera de lo que se enumera a continuación, por favor contacte a Google Cloud Support utilizando https://cloud.google.com/support. ## Date/Time of the Issue (All time US/Pacific) * Incident Start: 20 August 2026 08:00 * Fin del incidente: 20 de agosto de 2026 10:22 * Duración: 2 horas, 22 minutos ## Summary El jueves 20 de agosto de 2026, varios servicios de Google Cloud encontraron latencia elevada, fallos de provisión, aumento de las tasas de error y degradación de los servicios durante una duración de 2 horas y 22 minutos. ## Preliminary Root Cause La perturbación se originó durante el mantenimiento de fibra óptica programada, que comprometió inesperadamente la capacidad de red entre centros de datos dentro de la región nosotros-oeste1. Los mecanismos de red automatizados no redistribuyeron adecuadamente el tráfico a la capacidad alternada, lo que dio lugar a la congestión de redes a medida que los volúmenes superaron el ancho de banda disponible en la zona afectada. Esta degradación de la red subyacente repercutió posteriormente en los componentes de servicios de alto nivel mediante la solución de solicitudes, el aumento de la latencia y los depósitos de cascada. En consecuencia, tanto las operaciones aéreas de control como las solicitudes de avión de datos no se ejecutaron con éxito en varios servicios dependientes de Google Cloud, produciendo la latencia observada y tasas de error elevadas. ## Remediation Monitoreo interno alertó a los ingenieros de Google al incidente, confirmando que múltiples servicios a través de nosotros-oeste1 fueron afectados. Para mitigar los efectos operacionales inmediatos, los ingenieros iniciaron protocolos de drenaje de tráfico, reorientando la carga de trabajo de los servicios lejos de la infraestructura de red degradada. Tras el restablecimiento de la capacidad de red entre campamentos y la resolución de la cuestión central, los ingenieros restablecieron sistemáticamente el tráfico a la región nosotros-oeste y confirmaron la normalización de los servicios. Actualmente se están ultimando y asignando soluciones de ingeniería a largo plazo para abordar la causa raíz y fortalecer la resiliencia del sistema con respecto a los procedimientos de mantenimiento de la fibra. ## Descripción del impacto El jueves 20 de agosto, entre las 08:00 y las 10:22 EE.UU./Pacífico, los clientes de Google Cloud en la región nosotros-oeste1 encontraron una elevada latencia, fallos de provisión y mayores tasas de error. * Impacto proporcional / Tasas de error: El alcance preciso del impacto, incluida la proporción de proyectos y aplicaciones afectados, y las métricas detalladas de errores se publicarán en el análisis integral de la causa raíz, ya que la capacidad reducida causó la reducción de la solicitud de trinquete, picos de latencia y mayor volumen de reingreso. * Exclusión de alcance: Los servicios y las cargas de trabajo que operan en regiones distintas de nosotros-oeste1 siguieron siendo plenamente operacionales y no afectados. ** Servicios y características afectados** Los siguientes servicios experimentaron altas demoras y/o mayores tasas de error, en sus respectivos planos de datos y planos de control: * AlloyDB * Apache Kafka * Abigee Edge Public Cloud * Apigee X * Registro de artefactos * Servicio de transferencia de datos BigQuery * Cloud Build * Fusión de datos en la nube * Flujo de datos en la nube * Cloud Filestore * Servicio de Gestión Clave de Cloud (KMS) * Vigilancia de la nube * Cloud Run * Cloud SQL * Contact Center AI Platform * Dataproc Metastore * Google App Engine * Google Cloud Bigtable * Google Cloud Pub/Sub * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Gestión de identidad y acceso (IAM) * Managed Airflow (Cloud Composer) *Servicio gestionado para Apache Spark (Dataproc) Disco persistente

9. 27 de agosto de 2026 a las 21:45 UTCresolved

   # Incident Report ## Summary El jueves 20 de agosto de 2026, de 08:00 a 10:22 EE.UU./Pacífico (15:00 a 17:22 UTC), múltiples servicios de Google Cloud en la región nosotros-oeste1 experimentaron latencia elevada, la provisión de fallas, aumento de las tasas de error, y degradaciones de servicios generalizadas durante una duración total de 2 horas y 22 minutos. El incidente repercutió en una amplia gama de servicios básicos, como Persistent Disk, Google Kubernetes Engine, Google Compute Engine, Cloud Run, Google Cloud Bigtable, Cloud Storage, y Identity and Access Management, tanto en operaciones de control planas como en solicitudes de avión de datos. Sinceramente nos disculpamos por la perturbación de este incidente causado a sus operaciones comerciales y cargas de trabajo críticas. Reconocemos el papel vital que desempeña Google Cloud en el apoyo a su organización, y lamentamos profundamente el impacto en sus operaciones comerciales y cargas de trabajo críticas. Los equipos de ingeniería e infraestructura están aplicando activamente medidas para abordar las causas profundas y fortalecer la resiliencia de la red para prevenir las recurrencias en el futuro. Concretamente, los equipos están vigilando el progreso de la recuperación, refinando los controles de seguridad para el mantenimiento óptico previsto y optimizando los mecanismos regionales de enrutamiento de tráfico para salvaguardar contra las imprevistos limitaciones de capacidad. ## Root Cause La perturbación se originó durante el mantenimiento de fibra óptica programada, que comprometió inesperadamente la capacidad de red entre centros de datos dentro de la región nosotros-oeste1. Los mecanismos de red automatizados no redistribuyeron adecuadamente el tráfico a la capacidad alternada, lo que dio lugar a la congestión de redes a medida que los volúmenes superaron el ancho de banda disponible en la zona afectada. Esta degradación de la red subyacente repercutió posteriormente en los componentes de servicios de alto nivel a través de la pérdida severa del paquete, la petición de que prosperen y el aumento de la latencia entre las dependencias de los campamentos. Los servicios básicos de infraestructura, incluyendo el consenso de Spanner Paxos y el Servidor Unificado de Metadatos (UMS), experimentaron importantes picos de latencia, que encadenó en los timeouts y tasas de error elevadas para productos dependientes de aguas abajo como Cloud Storage, Cloud IAM, Persistent Disk y Google Kubernetes Engine. En consecuencia, tanto las operaciones aéreas de control como las solicitudes de avión de datos no se ejecutaron con éxito a través de múltiples servicios de Google Cloud en nosotros-oeste1 durante la duración del incidente. ## Remediation and Prevention Los sistemas de vigilancia interna detectaron inicialmente anomalías de servicio generalizadas y alertaron a los ingenieros de Google, quienes confirmaron rápidamente que múltiples servicios básicos que operaban a través de la región nosotros-oeste1. En respuesta a los riesgos operacionales inmediatos, los equipos de ingeniería ejecutaron rápidamente protocolos de desagüe de tráfico de emergencia para desviar la carga de trabajo de servicios activos de la infraestructura de red entre campamentos comprometida y reducir al mínimo la perturbación de los clientes. Una vez que los equipos restablecieron la capacidad de red de fibra entre campamentos, los ingenieros reintroducieron sistemáticamente el tráfico de producción a nosotros-oeste1 mediante etapas de validación controladas, confirmando finalmente la normalización completa del servicio en todas las plataformas impactadas. Se están finalizando activamente las remediaciones de ingeniería a largo plazo y las mejoras arquitectónicas que se asignan a los equipos de propiedad. Las principales esferas prioritarias incluyen la reforma de los protocolos de mantenimiento programados, el establecimiento de controles de seguridad más estrictos y requisitos de redundancia en los circuitos antes del mantenimiento rutinario, y la refinación de mecanismos automatizados de reducción de tráfico regional para manejar automáticamente la degradación repentina de la capacidad sin incurrir en una intensa congestión de red. ## Descripción detallada del impacto El jueves 20 de agosto, entre las 08:00 y las 10:22 EE.UU./Pacífico, los clientes de Google Cloud en la región nosotros-oeste1 encontraron una elevada latencia, fallos de provisión y mayores tasas de error. * **Impact / Tasas de error:** La reducción de la capacidad causó el agitamiento de la solicitud, los picos de latencia y el aumento del volumen de reingreso. * **Exclusión de la piel* Los servicios y la carga de trabajo que operan en regiones distintas de nosotros y el oeste1 siguieron siendo plenamente operacionales y no afectados. ** Servicios y características afectados** Los siguientes servicios experimentaron altas demoras y/o mayores tasas de error, en sus respectivos planos de datos y planos de control: * AlloyDB * Apache Kafka * Abigee Edge Public Cloud * Apigee X * Registro de artefactos * Servicio de transferencia de datos BigQuery * Cloud Build * Fusión de datos en la nube * Flujo de datos en la nube * Cloud Filestore * Servicio de Gestión Clave de Cloud (KMS) * Vigilancia de la nube * Cloud Run * Cloud SQL * Contact Center AI Platform * Dataproc Metastore * Google App Engine * Google Cloud Bigtable * Google Cloud Pub/Sub * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Gestión de identidad y acceso (IAM) * Managed Airflow (Cloud Composer) * Servicio gestionado para Apache Spark (Dataproc) * Disco persistente The regional incident in us-west1 followed a structured three-phase recovery dictated by platform dependncy layers: Mientras que la conectividad de la plataforma central y el servicio de solicitud en vivo fueron restaurados por 10:22 EE.UU./Pacífico, algunos servicios tomaron tiempo adicional para recuperarse completamente debido al procesamiento atrasado asincrónico y la reconciliación estatal de plan de control localizada para un conjunto muy pequeño de clientes. Para los servicios impulsados por eventos y oleoductos, las tasas de errores de entrada disminuyeron a 0 inmediatamente, pero algunas operaciones experimentaron una elevada latencia mientras los trabajadores procesados a través de los atrasos acumulados durante el desembolso, aclarando más adelante para Cloud Pub/Sub, Cloud Build " Deploy, Cloud Dataflow y Cloud Storage Lifecycle deletions. Concurrently, while primary read/write traffic was healthy across the region, specific long-running lifecycle workflows required extra time to clear locks and reconcili distributed state machines. Compute Engine VM provisioning in zone us-west1-c and Cloud Filestore control plano instance allocation locks and resource validation checks took longer to normalize across regional storage backends.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de julio de 2026 a las 3:30 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services are experiencing temperature alerts in europe-west4-a. **Description** **GCVE:** Our engineering teams are currently working with data center facility teams to address the rising temperatures. A shutdown has already occurred for some private clouds, and we expect that others will shut down as well. **We recommend shutting down your VMware workload VMs for precaution so that recovery is safer. A shutdown of all systems started at 19:00 PDT \[4:00 Local Time (GMT+2)\]** We will notify you as soon as your Private Cloud has been powered back up and it is safe to restart the VMs. **BMS:** Some Bare Metal Solution servers are experiencing high temperatures and we are in the process of shutting them down. Customers may be unable to access their systems until we resolve the issue. **Google Cloud NetApp Volumes** Our engineering team has proactively shut down ONTAP clusters to protect the data stored on them. Customers may experience unavailability of Cloud NetApp Volumes until this issue is resolved. There is no estimated time for resolution. We will provide an update by Wednesday, 2026-07-15 21:30 PDT with current details. We apologize to all who are affected by the disruption. **Customer Symptoms** **GCVE:** Customers may have already observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and a recovery, we are shutting down all Private Clouds in this zone. **BMS:** Customers may have already lost connectivity to their BMS machines. As a protective measure for hardware integrity and a recovery, we are shutting down servers in this zone. **Google Cloud NetApp Volumes** Customers may have already lost connectivity to ONTAP clusters, or will lose connectivity to them shortly, as we proactively shut them down for their protection. Only Standard, Premium, and Extreme service levels are affected. **Workaround** There are no workarounds available for this issue at this time. Customers with multi-regional deployments are advised to route traffic to an alternate site.

2. 16 de julio de 2026 a las 4:17 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services are experiencing temperature alerts in europe-west4-a **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google has proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. The datacenter operator team is working diligently to bring cooling and power back online so we can safely restart affected workloads. **GCVE:** Our engineering teams have shut down private clouds, and we expect that others will shut down as well. We will notify customers as soon as their private cloud has been powered back up and it is safe to restart the VMs. **BMS:** Some Bare Metal Solution servers are experiencing high temperatures and we are in the process of shutting them down. Customers may be unable to access their systems until we resolve the issue. **Google Cloud NetApp Volumes** Our engineering team has proactively shut down ONTAP clusters to protect the data stored on them. Customers may experience unavailability of Cloud NetApp Volumes until this issue is resolved. There is no estimated time for resolution. We will provide an update by Wednesday, 2026-07-15 22:30 PDT with current details. We apologize to all who are affected by the disruption. **Customer Symptoms** **GCVE:** Customers would have already observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and a recovery, we have shut down all private clouds in this zone. **BMS:** Customers may have already lost connectivity to their BMS machines. As a protective measure for hardware integrity and a recovery, we are shutting down some servers in this zone. **Google Cloud NetApp Volumes** Customers would have already lost connectivity to ONTAP clusters, as we proactively shut them down for their protection. Only Standard, Premium, and Extreme service levels are affected. **Workaround** There are no workarounds available for this issue at this time. Customers with multi-regional deployments are advised to route traffic to an alternate site.

3. 16 de julio de 2026 a las 4:41 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services are experiencing a service outage in europe-west4-a due to a cooling failure **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google has proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. The datacenter operator team is working diligently to bring cooling and power back online so we can safely restart affected workloads. Some cooling has been restored, and we are working to restore affected workloads as available capacity allows. **GCVE:** Cooling has been restored at the site. As a precautionary measure, our engineering teams had shut down private clouds to protect these clouds from any damage. We are beginning service restoration and will notify customers as soon as their private cloud has been powered back up and it is safe to restart the VMs. **BMS:** Some Bare Metal Solution servers experienced high temperatures and we proactively shut them down. We are starting to bring the servers back online, and will provide an update once they are ready. Customers may be unable to access these systems until service is restored. **Google Cloud NetApp Volumes:** Our engineering team has proactively shut down ONTAP clusters to protect the data stored on them. Customers may experience unavailability of Cloud NetApp Volumes until this issue is resolved. There is no estimated time for resolution. We will provide an update by Wednesday, 2026-07-15 23:30 PDT with current details. We apologize to all who are affected by the disruption. **Customer Symptoms** **GCVE:** Customers would have already observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and recovery, we have shut down all private clouds in this zone. **BMS:** Customers may have lost connectivity to their BMS machines. As a protective measure for hardware integrity and recovery, we shut down some servers in this zone, and are actively restoring them. Customers may be unable to access these systems until restoration is complete. **Google Cloud NetApp Volumes:** Customers would have already lost connectivity to ONTAP clusters, as we proactively shut them down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels are affected. **Workaround** There are no workarounds available for this issue at this time. However, customers with multi-regional deployments are advised to route traffic to an alternate site.

4. 16 de julio de 2026 a las 6:29 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services are experiencing a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The datacenter operator team is now working to safely restart affected workloads. **GCVE:** As a precautionary measure, our engineering teams had shut down private clouds to protect these clouds from any damage. Service restoration is still in progress. We will notify customers as soon as their private cloud has been powered back up and it is safe to restart the VMs. **BMS:** We are continuing to restore servers and monitor their health. Customers may be unable to access these systems until service restoration is complete. **Google Cloud NetApp Volumes:** Our engineering team had proactively shut down ONTAP clusters to protect the data stored on them. Customers may experience unavailability of Cloud NetApp Volumes until this issue is resolved. We will provide an update by Thursday, 2026-07-16 00:30 PDT with current details. **Customer Symptoms** **GCVE:** Customers would have already observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and recovery, we have shut down all private clouds in this zone. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we shut down some servers in this zone. We are continuing to restore servers and monitor their health. Customers may be unable to access these systems until service restoration is complete. **Google Cloud NetApp Volumes:** Customers would have already lost connectivity to ONTAP clusters, as we proactively shut them down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels are affected. **Workaround** There are no workarounds available for this issue at this time. However, customers with multi-regional deployments are advised to route traffic to an alternate site.

5. 16 de julio de 2026 a las 7:39 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services are experiencing a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The datacenter operator team is now working to safely restart affected workloads. **GCVE:** As a precautionary measure, our engineering teams had shut down private clouds to protect these clouds from any damage. Network fabric has been restored, and Private Cloud restoration remains underway. We will notify affected customers once their Private Clouds are restored to allow for VM operational verification. **BMS:** We are continuing to restore servers and monitor their health. Customers may be unable to access these systems until service restoration is complete. **Google Cloud NetApp Volumes:** Our engineering team had proactively shut down ONTAP clusters to protect the data stored on them. Recovery is currently in progress. Customers may experience unavailability of Cloud NetApp Volumes until this issue is resolved. We will provide an update by Thursday, 2026-07-16 01:30 PDT with current details. **Customer Symptoms** **GCVE:** Customers would have already observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and recovery, we have shut down all private clouds in this zone. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we shut down some servers in this zone. We are continuing to restore servers and monitor their health. Customers may be unable to access these systems until service restoration is complete. **Google Cloud NetApp Volumes:** Customers would have already lost connectivity to ONTAP clusters, as we proactively shut them down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels are affected. **Workaround** There are no workarounds available for this issue at this time. However, customers with multi-regional deployments are advised to route traffic to an alternate site.

6. 16 de julio de 2026 a las 8:32 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services experienced a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The datacenter operator team is now validating site stability. **GCVE:** Network fabric has been restored, and Private Cloud restoration remains underway. We are notifying the affected customers as their Private Clouds are restored to allow for VM operational verification. **BMS:** Server restoration is largely complete, with most systems now online and reporting a healthy status. We are actively working through the remaining validation efforts to achieve full recovery. **Google Cloud NetApp Volumes:** Service restoration is complete, and all affected servers are now operational. We continue to monitor these for full service recovery. If customers are still experiencing impact from this issue, please contact Support, and we will work with you to resolve any residual impact. We will provide an update by Thursday, 2026-07-16 02:30 PDT with current details. **Customer Symptoms** **GCVE:** Customers would have observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and recovery, we had shut down all Private Clouds in this zone. We are in the process of bringing all restored Private Clouds online. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we had shut down some servers in this zone. We are continuing to restore servers and monitor their health. **Google Cloud NetApp Volumes:** Customers would have lost connectivity to ONTAP clusters, as they were proactively shut down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels were affected. Customers should now be able to access their volumes again. **Workaround** There are no workarounds available for this issue at this time. However, customers with multi-regional deployments are advised to route traffic to an alternate site.

7. 16 de julio de 2026 a las 9:21 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services experienced a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The datacenter operator team is now validating site stability. **GCVE:** Network fabric has been restored, and Private Cloud restoration remains underway. We are notifying the affected customers as their Private Clouds are restored to allow for VM operational verification. **BMS:** Server restoration is largely complete, with most systems now online and reporting a healthy status. We are actively working through the remaining validation efforts to achieve full recovery. **Google Cloud NetApp Volumes:** Service restoration is complete, and all affected servers are now operational. We continue to monitor these for full service recovery. If customers are still experiencing impact from this issue, please contact Support, and we will work with you to resolve any residual impact. We will provide an update by Thursday, 2026-07-16 03:30 PDT with current details. **Customer Symptoms** **GCVE:** Customers would have observed a loss of connectivity to their private cloud. As a protective measure for hardware integrity and recovery, we had shut down all Private Clouds in this zone. We are in the process of bringing all restored Private Clouds online. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we had shut down some servers in this zone. We are continuing to restore servers and monitor their health. **Google Cloud NetApp Volumes:** Customers would have lost connectivity to ONTAP clusters, as they were proactively shut down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels were affected. Customers should now be able to access their volumes again. **Workaround** None at this time.

8. 16 de julio de 2026 a las 10:14 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services experienced a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The issue with GCVE and Google Cloud NetApp Volumes has been resolved for all affected users. We continue to recover the impact for BMS at the moment. **GCVE [Mitigated]:** Service restoration is complete across all the Private Clouds. Customers have been informed about this restoration and requested to verify that their VMs are fully operational. **Google Cloud NetApp Volumes [Mitigated]:** Service restoration is complete, and all affected servers are now operational. We continue to monitor these for full service recovery. **BMS:** Server restoration is largely complete, with most systems now online and reporting a healthy status. We are actively working through the remaining validation efforts to achieve full recovery. For Google Cloud NetApp Volumes and GCVE, if customers are still experiencing impact from this issue, please contact Support, and we will work with you to resolve any residual impact. We will provide the BMS restoration status update by Thursday, 2026-07-16 04:30 PDT with current details. **Customer Symptoms** The issue is now resolved for GCVE and Google Cloud NetApp Volumes. We continue to recover the impact for BMS at the moment. **GCVE [Mitigated]:** Customers would have observed a loss of connectivity to their private cloud. **Google Cloud NetApp Volumes [Mitigated]:** Customers would have lost connectivity to ONTAP clusters, as they were proactively shut down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels were affected. Customers should now be able to access their volumes again. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we had shut down some servers in this zone. We are continuing to restore servers and monitor their health. **Workaround** None at this time.

9. 16 de julio de 2026 a las 11:39 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services experienced a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The issue with GCVE and Google Cloud NetApp Volumes has been resolved for all affected users. We continue to recover the impact for BMS at the moment. **GCVE [Mitigated]:** Service restoration is complete across all the Private Clouds. Customers have been informed about this restoration and requested to verify that their VMs are fully operational. **Google Cloud NetApp Volumes [Mitigated]:** Service restoration is complete, and all affected servers are now operational. We continue to monitor these for full service recovery. **BMS:** Server restoration is largely complete, with most systems now online and reporting a healthy status. We are actively working through the remaining validation efforts to achieve full recovery. For Google Cloud NetApp Volumes and GCVE, if customers are still experiencing impact from this issue, please contact Support, and we will work with you to resolve any residual impact. We will provide the BMS restoration status update by Thursday, 2026-07-16 05:30 PDT with current details. **Customer Symptoms** The issue is now resolved for GCVE and Google Cloud NetApp Volumes. We continue to recover the impact for BMS at the moment. **GCVE [Mitigated]:** Customers would have observed a loss of connectivity to their private cloud. **Google Cloud NetApp Volumes [Mitigated]:** Customers would have lost connectivity to ONTAP clusters, as they were proactively shut down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels were affected. Customers should now be able to access their volumes again. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we had shut down some servers in this zone. We are continuing to restore servers and monitor their health. **Workaround** None at this time.

10. 16 de julio de 2026 a las 12:25 UTCresolved

    **Summary** Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solution (BMS) services experienced a service outage in europe-west4-a due to a cooling failure. **Description** The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure. Google proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment. Cooling and power have been restored at the site. The issue with GCVE and Google Cloud NetApp Volumes has been resolved for all affected users as of Thursday, 2026-07-16 02:31 PDT and 01:00 PDT respectively. The issue with BMS is largely resolved and is believed to be affecting a very small number of customers. Our Engineering will continue to recover this residual impact directly with the impacted customers. If you have questions or are still impacted, please open a case with the Support Team and we will work with you until this issue is resolved. **GCVE:** Service restoration is complete across all the Private Clouds. Customers have been informed about this restoration and requested to verify that their VMs are fully operational. **Google Cloud NetApp Volumes:** Service restoration is complete, and all affected servers are now operational. **BMS:** Service restoration is largely complete. We continue working with a very small number of remaining affected customers to achieve full recovery. We thank you for your patience while we continue to fully resolve the issue. **Customer Symptoms** The issue is now resolved for GCVE and Google Cloud NetApp Volumes. The issue with BMS is largely resolved and our engineering will continue to recover this residual impact directly with the impacted customers. **GCVE:** Customers would have observed a loss of connectivity to their private cloud. **Google Cloud NetApp Volumes:** Customers would have lost connectivity to ONTAP clusters, as they were proactively shut down to protect these clusters from any damage. Only Standard, Premium, and Extreme service levels were affected. **BMS:** Customers may have lost connectivity to their servers. As a protective measure for hardware integrity and recovery, we had shut down some servers in this zone. **Workaround** None at this time.

11. 18 de julio de 2026 a las 0:22 UTCresolved

    # Preliminary Incident Report We sincerely apologize for the disruption this incident caused to your business. We know how much you rely on Google Cloud, and we regret the impact on your productivity. Please note, this information is based on our best knowledge at the time of posting and is subject to change as our investigation continues. A final Incident Report with preventative actions will be posted once our investigation is complete. If you have experienced impact outside of what is listed below, please reach out to Google Cloud Support using https://cloud.google.com/support. ## Date/Time of the Issue (All time US/Pacific) **Google Cloud VMware Engine Impact:** - Start: 15 July 2026 17:09 - End: 16 July 2026 2:33 - Duration: 9 Hours, 24 Minutes **Google Cloud NetApp Volumes Impact:** - Start: 15 July 2026 16:39 - End: 16 July 2026 01:10 - Duration: 8 Hours 31 Minutes **Bare Metal Solution Impact:** - Start: 15 July 2026 18:37 - End: 16 July 2026 07:34 - Duration: 12 Hours 57 Minutes ## Summary On Wednesday, 15 July 2026, Google Cloud VMware Engine, Bare Metal Solution, and Google Cloud NetApp Volumes experienced service interruptions for a total duration of 14 hours, 55 minutes. We are taking immediate steps to ensure this doesn’t happen again. ## Preliminary Root Cause A regional data center hosting services in europe-west4-a experienced a loss of utility power and subsequent cooling capacity. The sequence of events leading to customer impact was as follows: - An electrical fault occurred on the utility grid upstream of the data center, disrupting the electrical distribution gear and cooling equipment. - The loss of cooling infrastructure resulted in ambient temperatures rising rapidly within the affected data halls. Host servers, storage clusters, and network switches were shut down to prevent equipment damages due to the extreme heat. - The high temperatures in the data hall resulted in disruption to customer workloads and control plane operations across the affected services. Google engineers have begun a full root cause analysis and we will provide additional information once it is available. ## Remediation Google engineering teams were alerted to the issue via automated temperature and hardware unreachability telemetry starting at 16:39 US/Pacific. Engineers collaborated with the third-party facility provider to safely restore primary utility power and cooling systems, returning ambient room temperatures to safe operational levels. With the environment stabilized, field support engineers and remote teams systematically booted and verified the server hosts, storage nodes, and network fabric in a controlled sequence. Automated recovery playbooks were executed to restore underlying network switches and routing infrastructure, allowing storage appliances and compute clusters to be brought back online and verified for health. The underlying infrastructure has been fully recovered, and normal operations have been successfully restored. ## Description of Impact On 15 July 2026 from 16:39 to 16 July 2026 07:34 US/Pacific, customers experienced service disruptions across several products in europe-west4-a zone: - **Google Cloud VMware Engine:** Customers lost connectivity to their private clouds and workloads as foundational hosts and network switches were powered off for thermal protection. - **Bare Metal Solution:** Customers experienced connectivity loss to their database servers and storage appliances as the underlying hardware was powered down. - **Google Cloud NetApp Volumes:** Customers in the STANDARD, PREMIUM, and EXTREME service levels were unable to access their storage volumes. Control plane operations, including the creation of new storage pools, volumes, and backups, experienced failures in the affected region.

12. 25 de julio de 2026 a las 13:16 UTCresolved

    ## \# Incident Report ## \#\# Summary On Wednesday, 15 July 2026, Google Cloud VMware Engine (GCVE), Bare Metal Solution (BMS), and Google Cloud NetApp Volumes (GCNV) experienced service interruptions for a total duration of 14 hours, 55 minutes. The root cause for this outage is a 3ms voltage drop in the power feed from the utility provider and subsequent utility breaker protective action. This incident was mitigated by the data center provider rectifying the failed systems followed by the Google engineering team restoring the services. ## \#\# Root Cause A regional data center hosting services in europe-west4-a experienced an upstream voltage transient affecting both utility power feeds A and B. During this event, the utility breakers on both A and B feeds tripped and initiated the transfer to the back-up power source DRUPS (Diesel Rotary Uninterruptible Power Supply). The transition of side B to DRUPS system was successful without any power interruption. The DRUPS back-up power system for side A failed to take over the facility load due to electrical component failures. The DRUPS failure to take over load initiated automatic transfer of the affected 3 rows from feed A to redundant power feed B. Rows 1 and 2 transferred to power feed B successfully. Row 3 failed to transfer to power feed B and experienced complete power loss due to an overload protection breaker trip. The root cause of the failed transfer on the affected row was identified as load deployment discrepancy which is under further investigation by Google engineering team. This resulted in loss of both redundant power feeds to the single row. During the voltage transient event, the server data hall experienced an increased temperature due to a cooling system failure. The chiller controller dropped offline during the voltage transient event, failing to signal the chilled water distribution pumps to restart and ultimately causing the chiller system A to shut down. The redundant source was not available due to known ongoing construction work at the facility. This resulted in the data hall temperatures reaching 44°C and subsequent shutdown of the affected data hall machines. Google engineering teams initiated machine shutdown procedures for the remainder of reachable devices as part of the cooling emergency shutdown process. A timeline of events during the incident is provided below. ### DataCenter Events | Timestamp(PST) | Event Description | | :---- | :---- | | 07-15-2026 16:24 | An electrical fault occurred on the utility grid upstream of the data center, disrupting the electrical distribution. | | 07-15-2026 16:24 | DRUPS back-up power system for side A failed to take over the data hall load. | | 07-15-2026 16:24 | The chiller controller dropped offline during the voltage transient event causing distribution pumps to stop and unable to restart. | | 07-15-2026 16:37 | Rows 1 and 2 transferred to power feed B successfully. Row 3 failed to transfer to power feed B and lost power. | | 07-15-2026 18:29 | Data hall temperatures reached 44C and crossed the safe machine operating threshold. | | 07-15-2026 19:55 | Machine shutdown procedures implemented. | | 07-15-2026 21:05 | Cooling system fully recovered and temperatures in the data hall returned to normal operating range. | | 07-15-2026 21:24 | Notification about cooling recovery sent by provider | | 07-15-2026 21:46 | Notification about power recovery sent by provider | ### GCVE Timelines | Timestamp(PST) | Event Description | | :---- | :---- | | 07-15-2026 16:30 | GCVE service power monitoring alert received | | 07-15-2026 16:41 | First symptom detected, servers reporting redundancy power feed failure. | | 07-15-2026 17:05 | Switch temperature \>60°C alerts triggered. | | 07-15-2026 17:09 | Start of user impact, first prober alert failure for north south traffic for customers. | | 07-15-2026 19:00 | Server / Network devices shutdown initiated. | | 07-15-2026 19:55 | All reachable server/network devices were shut down. | | 07-15-2026 21:24 | Cooling system fully recovered and temperatures in the datahall were returning to normal operating range. | | 07-15-2026 21:56 | Network restoration started with reachable hydra devices. | | 07-15-2026 22:40 | Onsite technician arrived, to recover the console servers. | | 07-15-2026 23:10 | Console server reboot/recovery complete. | | 07-16-2026 00:33 | Network recovery for all Placement Groups complete. | | 07-16-2026 02:36 | Incident mitigated, after recovering all the customer PCs are fully healthy. | This outage impacted 24 private clouds of 20 distinct customers in europe-west4-a region. ### Bare Metal Solutions (BMS) Timelines | Timestamp(PST) | Event Description | | :---- | :---- | | 07-15-2026 16:41 | First symptom detected, servers and storage reporting redundancy power feed failure | | 07-15-2026 17:52 | Automated monitoring detected rising temperatures | | 07-15-2026 18:37 | Four Netapp SAN storage nodes failed and were shut down due to overheating, resulting in storage availability issue | | 07-15-2026 18:37 | Customer impact started, first server shutdown detected | | 07-15-2026 18:59 | Reserve and buffer servers started to get powered off | | 07-15-2026 20:43 | Drop in the temperature has been detected | | 07-15-2026 20:52 | Four Netapp SAN storage nodes recovered, mitigating storage availability issue | | 07-15-2026 21:05 | The cooling system fully recovered and temperatures in the datahall were returning to normal operating range. | | 07-15-2026 23:23 | First customer server reboot started | | 07-16-2026 06:32 | Last customer server reboot started | | 07-16-2026 08:42 | Incident mitigated. All impacted customer servers were rebooted and confirmed in healthy state. | This outage impacted 9 distinct BMS customers in europe-west4 ### NetApp Timelines | Timestamp(PST) | Event Description | | :---- | :---- | | 07-15-2026 16:32 | Netapp facility remote monitoring alert on high temp and network switches switches failure received | | 07-15-2026 17:32 | All 6 clusters failed and were shut down automatically due to high temperature | | 07-15-2026 21:05 | Cooling capacity restored | | 07-15-2026 22:08 | Cluster recovery process initiated for all 6 clusters. 1st cluster recovered | | 07-15-2026 23:55 | All 6 Netapp Clusters and all customers recovered and validated as healthy & operational | ## \#\# Remediation and Prevention Google engineers were alerted to the infrastructure power loss on Wednesday, 15 July 2026 at 16:30 US/Pacific and subsequent increase in data hall temperatures at 17:44 US/Pacific via our automated monitoring and telemetry, and immediately began investigating. During the voltage transient event, the chillers maintained power but shut down because the distribution pumps failed to restart, resulting in no water flow. The pumps were manually switched from auto to hand mode to restore circulation and cooling. The facility team deployed an interim portable UPS to support the chiller controllers and prevent localized controller power loss. Upon confirmation of utility power restoration, the facility returned to utility power via automatic switching with the exception of two Remote Power Panels (RPPs), which required manual verification before restoration of power to affected server row. To provide full resiliency the facility team aligned a swing DRUPS unit to restore the redundant configuration on the A feed and is working on repairing the faulty DRUPS. To remediate the power loss at Row 3, once the electrical fault was confirmed to be fully isolated, teams reset the tripped breakers, successfully restoring both redundant power to the impacted server racks. Google is committed to preventing a repeat of this issue in the future and is completing the following actions: * Detailed investigation by the engineering team of the sequence of events that prevented transfer of load to DRUPS system and identified system improvements **\[ETA Aug 2026\].** * Determine and resolve the cause of overload conditions that caused power loss to Row 3 **\[ETA Aug 2026\].** * Perform investigation of chiller pump control system redundancy setup to ensure cooling system resiliency **\[ETA Sep 2026\].** * Implement improvements to facility system monitoring alerts for power events and configure early alert thresholds for cooling excursion detection. **\[ETA Aug 2026\].** * The GCVE engineering team is working to improve the automated triggering of shutdown during quickly evolving thermal runoff situations **\[ETA Oct 2026\]**. * The BMS engineering team is working with partner teams to update the incident classification and SLO definitions to improve personnel availability during major datacenter events **\[ETA Sep 2026\]**. * The GCNV engineering team is collaborate with the data center team to review incident handling SLA and runbooks, identify potential future occurrences and create playbooks to address/mitigate them, establish monthly joint emergency drill, and review if the Netapp cluster recovery process can be expedited **\[ETA Aug 2026\].** ## \#\# Detailed Description of Impact On 15 July 2026 from 16:39 to 16 July 2026 07:34 US/Pacific, customers experienced service disruptions across several products in europe-west4-a zone: * **Google Cloud VMware Engine**: Customers lost connectivity to their private clouds and workloads as foundational hosts and network switches were powered off for thermal protection. * **Bare Metal Solution**: Customers experienced connectivity loss to their database servers and storage appliances as the underlying hardware was powered down. * **Google Cloud NetApp Volumes**: Customers in the STANDARD, PREMIUM, and EXTREME service levels were unable to access their storage volumes. Control plane operations, including the creation of new storage pools, volumes, and backups, experienced failures in the affected region.

1. 14 de julio de 2026 a las 20:24 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an issue with Google Cloud VMware Engine (GCVE) beginning Tuesday, 2026-07-14 at 10:00 PDT. We are continuing to investigate and mitigate the issue. We believe this disruption is isolated to network connectivity issues for stretch clusters, while Storage and Compute services appear to be unaffected. GCVE VMs are running as expected but customers may experience connectivity issues to the VMs. We will provide another update by Tuesday, 2026-07-14 14:00 PDT with current details. **Customer Symptoms** Some GCVE customers may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** None at this time.

2. 14 de julio de 2026 a las 21:31 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. Our preliminary investigation indicates this is stemming from an underlying network connectivity issue affecting the infrastructure that links the zones within a stretch cluster. This disruption is causing synchronization issues between the affected zones. We believe Storage and Compute services remain unaffected, and VMs are running as expected, though connectivity to them may be degraded. We will provide another update by Tuesday, 2026-07-14 15:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

3. 14 de julio de 2026 a las 22:16 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. Our investigation has identified underlying inter-zone communication failures and Border Gateway Protocol (BGP) session flapping between cluster zones. Specifically, network connectivity has been lost between the affected zones and the witness appliance. Because the witness appliance is currently unreachable, the cluster zones are unable to safely synchronize state. As a result, VMs on the affected sites are becoming isolated and may be left without writable data. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 16:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

4. 14 de julio de 2026 a las 23:05 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. Our investigation has identified a recent configuration update that is the likely cause of the inter-zone network disruption. Teams are working on remediation. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 17:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

5. 15 de julio de 2026 a las 0:13 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. A remediation rollout is currently in progress to address the underlying network issue. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 18:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. Upon further investigation we identified that the northamerica-northeast2 region was not impacted. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

6. 15 de julio de 2026 a las 1:15 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. A remediation rollout is currently in progress to address the underlying network issue. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 19:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

7. 15 de julio de 2026 a las 1:55 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. A remediation rollout is currently in progress to address the underlying network issue. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 20:30 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following workarounds to restore access to your workloads: - VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Support before proceeding.

8. 15 de julio de 2026 a las 3:27 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions. **Description** We are experiencing an inter-site communication issue with Google Cloud VMware Engine (GCVE) stretched cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We have identified the customers that are affected by this issue and we are working with them on mitigation. A remediation rollout is currently in progress to address the underlying network issue. **Failover / VM Migration:** Migrating affected VMs to the healthy, secondary zone of your stretch cluster remains the primary mitigation strategy. Because of the complexities surrounding failover risks and secondary zone health, we highly encourage you to open a ticket with Google Cloud Support if you are severely impacted. We do not currently have an ETA for resolution. We will provide another update by Tuesday, 2026-07-14 22:00 PDT with current details. **Customer Symptoms** Some GCVE customers using Stretched Cluster may experience inter-site communication failures to their GCVE environments within the affected zones. **Workaround** While we work on restoring full connectivity, we recommend the following to restore access to your workloads: * VM Migration (recommended): Where possible, migrate your affected VMs to the healthy and unaffected side of the stretch cluster. We strongly recommend consulting with Google Cloud Support before proceeding.

9. 15 de julio de 2026 a las 5:34 UTCresolved

   **Summary** Google Cloud VMware Engine (GCVE) Stretched Cluster customers may have experienced zonal outages impacting network connectivity across multiple regions. **Description** We experienced an inter-site communication issue with Google Cloud VMware Engine (GCVE) Stretched Cluster customers beginning Tuesday, 2026-07-14 at 10:00 PDT. We identified the affected customers, and have worked with them to fully mitigate the issue by Tuesday, 2026-07-14 at 21:46 PDT. Preliminary analysis indicates that a network configuration update was the cause of the inter-zone network disruption. Our engineering team mitigated the issue by rolling back the faulty configuration to its last-known good value. If customers are still experiencing impact from this issue, please contact Support, and we will work with you to resolve any residual impact. We thank you for your patience while we worked to resolve this issue. **Customer Symptoms** Some GCVE customers using Stretched Cluster may have experienced inter-site communication failures to their GCVE environments within the affected zones. **Workaround** The issue is now mitigated.

10. 20 de julio de 2026 a las 18:31 UTCresolved

    ## Preliminary Incident Report We sincerely apologize for the disruption this incident caused to your business. We know how much you rely on Google Cloud, and we regret the impact on your productivity. We are working to address the root cause and prevent this from occurring in the future. Please note, this information is based on our best knowledge at the time of posting and is subject to change as our investigation continues. A final Incident Report with preventative actions will be posted once our investigation is complete. If you have experienced impact outside of what is listed below, please reach out to Google Cloud Support using [**https://cloud.google.com/support**](https://cloud.google.com/support). ## Date/Time of the Issue (All time US/Pacific) Incident Start: 14 July 2026 10:00 Incident End: 14 July 2026 20:40 Duration: 10 hours, 40 minutes ## Summary On Tuesday, 14 July 2026, Google Cloud VMware Engine (GCVE) Stretched Cluster customers in the australia-southeast2 and europe-west3 zones experienced inter-site communication failures. The disruption was traced to a network configuration update that introduced a conflict, causing inter-site communication failures, which triggered VMware Stretch Cluster failover events. Google engineers successfully mitigated the disruption by rolling back the configuration change. ## Preliminary Root Cause A configuration change deployed within the Google Cloud network affected traffic between the VMware Engine stretched cluster zones. This resulted in a loss of connectivity between zones in the stretched cluster deployment. Google engineers are doing a full root cause analysis and will provide additional information once it is available. ## Remediation To stabilize the environment, engineers identified the working network paths and deployed configuration changes to reroute traffic and restore connectivity. GCVE stretch cluster inter-zonal connectivity was completely restored for all supported locations on Tuesday, 14 July 2026 at 20:40 US/Pacific. ## Description of Impact On Tuesday, 14 July 2026 from 10:00 to 20:40 US/Pacific, customers utilizing GCVE stretch clusters in the affected zones (australia-southeast2, and europe-west3) experienced inter-site communication failures. For some customers, depending on their architecture, this disruption led to VMWare HA event causing VM restarts/movement across zones as designed, Host disconnects, VSAN alarms and Intermittent access to VMware Management (vCenter/NSX Manager) components. ---

11. 24 de julio de 2026 a las 7:10 UTCresolved

    ## Incident Report ## Summary On Tuesday, 14 July 2026 10:00 PT, Google Cloud VMware Engine (GCVE) Stretched Cluster customers in the australia-southeast2 and europe-west3 zones experienced inter-site communication failures. The disruption was traced to a network configuration update that introduced a conflict, causing inter-site communication failures, which triggered VMware Stretched Cluster failover events. Google engineers successfully mitigated the impact by rolling back the issue-causing configuration change and resetting the network state. We sincerely apologize for the disruption this incident caused to your business. We know how much you rely on Google Cloud, and we regret the impact on your productivity. We are working to address the root cause and prevent this from occurring in the future. ## Root Cause A network configuration update intended to prepare the cloud network infrastructure for new capabilities was deployed to the foundational network control plane. While the configuration payload itself was structurally valid, it exposed an implementation gap within the control plane's routing logic. This logical gap caused the underlying network hosts to misconfigure program routing tables. As a result, traffic destined for the private IP address space used by GCVE Stretched Clusters was dropped. Because Stretched Clusters rely on this private address space to establish routing sessions for inter-zonal connectivity, the traffic drops severed communications between the active zones of the clusters, triggering VMware High Availability (HA) failovers. Standard routing health-checking protocols, such as Border Gateway Protocol (BGP) and Bidirectional Forwarding Detection (BFD), remained fully functional because their control plane sessions run on separate, unaffected address spaces. Because the control plane remained healthy, standard failover mechanisms failed to detect that the selective private IP range used for inter-zonal data tunneling was being dropped. Automated safeguards did not block the deployment because the configuration passed initial payload validations. The impact only manifested once the update began routing data traffic through the specific affected IP range. ## Remediation and Prevention To stabilize the environment, engineers identified the working network paths and deployed configuration changes to reroute traffic and restore connectivity. GCVE Stretched Cluster inter-zonal connectivity was completely restored for all supported locations on Tuesday, 14 July 2026 at 20:40 US/Pacific. Google is committed preventing a repeat of this issue in the future and is completing the following actions: * **Expanded Testing:** We are adding more detailed GCVE network setups to our existing testing environments. This allows us to automatically test future network updates against these configurations before they go live. * **Service-Level Data Path Failover:** We are implementing additional service-level data path failover mechanisms that actively probe the specific data-tunneling traffic space. This will ensure a path failover is triggered if the data plane itself is degraded even when the BGP control plane remains functional. * **Detailed Alerting**: We are adding faster, more specific alerts for connection issues between zones. This builds on our current platform monitoring to catch minor disruptions early and speed up our response. * **Improved Cluster Resilience:** We are fine-tuning the cluster's high-availability and storage settings. This makes virtual machines more resilient to short network drops, preventing them from restarting unnecessarily if the main site is still healthy. * **Workload Resilience Alignment (Shared Responsibility):** We are proactively reaching out to customers utilizing non-vSAN replicated virtual machine configurations within Stretched Clusters. Because these workloads are pinned to a single zone without active cross-site replication, they cannot survive inter-site network disruptions. We are ready to assist customers in auditing their storage policies, adjusting Stretched Cluster configurations, and planning the secondary zone capacity required to enable robust high-availability failovers. ## Detailed Description of Impact On Tuesday, 14 July 2026 from 10:00 to 20:40 US/Pacific, customers utilizing GCVE Stretched Clusters in the affected zones (australia-southeast2, and europe-west3) experienced inter-site communication failures. For some customers, depending on their architecture, this disruption led to a VMWare HA event causing VM restarts/movement across zones as designed, host disconnects, VSAN alarms and intermittent access to VMware Management (vCenter/NSX Manager) components.

1. 10 de junio de 2026 a las 1:13 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area. We rerouted significant traffic from the impacted facility in Delhi to address reduced local serving capabilities. As a result, a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers may be impacted by the routing changes made to address reduced local, latency-optimized serving capabilities in Delhi. Affected customers may experience intermittent latency spikes due to demand exceeding capacity across Indian metros and regional ISPs. We are investigating additional traffic mitigations and Internet Edge peering augmentation to alleviate the latency issues affecting our customers. We will provide our next update by Wednesday, 2026-06-10 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

2. 10 de junio de 2026 a las 22:25 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area. We rerouted significant traffic from the impacted facility in Delhi to address reduced local serving capabilities. As a result, a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers may be impacted by the routing changes made to address reduced local, latency-optimized serving capabilities in Delhi. Affected customers may experience intermittent latency spikes due to demand exceeding capacity across Indian metros and regional ISPs. We are investigating additional traffic mitigations and Internet Edge peering augmentation to alleviate the latency issues affecting our customers. We are continuing to work with the ISP partners in the region to mitigate any additional impact from unplanned failures. We will provide our next update by Thursday, 2026-06-11 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

3. 11 de junio de 2026 a las 23:25 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area. We rerouted significant traffic from the impacted facility in Delhi to address reduced local serving capabilities. As a result, a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers may be impacted by the routing changes made to address reduced local, latency-optimized serving capabilities in Delhi. Affected customers may experience intermittent latency spikes due to demand exceeding capacity across Indian metros and regional ISPs. Initial traffic mitigations have yielded positive results for some Cloud customers. In parallel, we are pursuing additional Internet Edge peering capacity to reduce existing fragility in the metro. We are also optimizing capacity across network backbones to increase additional headroom for VPC customers in the affected region. Additionally, we are planning to augment our local Delhi POP and migrating select peering partners to further increase regional capacity. We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Friday, 2026-06-12 at 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

4. 12 de junio de 2026 a las 22:50 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area. We rerouted significant traffic from the impacted facility in Delhi to address reduced local serving capabilities. As a result, a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers may be impacted by the routing changes made to address reduced local, latency-optimized serving capabilities in Delhi. Affected customers may experience intermittent latency spikes due to demand exceeding capacity across Indian metros and regional ISPs. Initial traffic mitigations have yielded positive results for some Cloud customers. In parallel, we are pursuing additional Internet Edge peering capacity to reduce latency in the local Delhi metropolitan area. Further, we are augmenting out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India (expected to be done by Wednesday, 2026-06-17 PDT). We have optimized capacity across network backbones to increase available headroom. Additionally, we are further augmenting our Delhi backbone capacity (expected to be complete by Monday, 2026-06-15 PDT). We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Monday, 2026-06-15 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

5. 15 de junio de 2026 a las 23:11 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** A fire at a third-party data center facility required an emergency power shutdown of networking equipment, isolating a non-compute local Point of Presence (POP) in Delhi and reducing available network capacity in the metro area. We rerouted significant traffic from the impacted facility in Delhi to address reduced local serving capabilities. As a result, a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers may be impacted by the routing changes made to address reduced local, latency-optimized serving capabilities in Delhi. Affected customers may experience intermittent latency spikes due to demand exceeding capacity across Indian metros and regional ISPs. Media CDN customers may have experienced higher latencies than normal. Initial traffic mitigations have yielded positive results for some Cloud customers. We have restored a portion of Internet Edge peering capacity to reduce latency in the local Delhi metropolitan area. Further, we are augmenting out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India (expected to be done by Wednesday, 2026-06-17 PDT). We have optimized capacity across network backbones to increase available headroom. Additionally, we have augmented our Delhi backbone capacity over the weekend. We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Wednesday, 2026-06-17 at 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

6. 17 de junio de 2026 a las 22:36 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** Traffic rerouting from the impacted Delhi facility has caused a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers to experience intermittent latency spikes as demand exceeds regional capacity. Media CDN customers may also notice increased latencies. Initial traffic mitigations have yielded positive results for some Cloud customers. We have restored a portion of Internet Edge peering capacity to reduce latency in the local Delhi metropolitan area. Further, we are nearly finished with the augmentation of out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India. We have optimized capacity across network backbones to increase available headroom. Additionally, we have augmented our Delhi backbone capacity. We have also restored additional capacity between Delhi-Chennai and Delhi-Mumbai. We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Monday, 2026-06-22 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

7. 22 de junio de 2026 a las 23:51 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** Traffic rerouting from the impacted Delhi facility has caused a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers to experience intermittent latency spikes as demand exceeds regional capacity. Media CDN customers may also notice increased latencies. Initial traffic mitigations have yielded positive results for some Cloud customers. We have restored a large portion of Internet Edge peering capacity to reduce latency in the local Delhi metropolitan area. Since the last update, we have completed the augmentation of out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India. Following safety clearance, teams obtained access to the damaged site and will further restore additional incremental user-facing backbone capacity on Tuesday, 2026-06-23. We have optimized capacity across network backbones to increase available headroom, and augmented our Delhi user-facing backbone capacity. We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Tuesday, 2026-06-23 at 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

8. 23 de junio de 2026 a las 22:52 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss. **Description** Traffic rerouting from the impacted Delhi facility has caused a subset of Hybrid Connectivity and Virtual Private Cloud (VPC) customers to experience intermittent latency spikes as demand exceeds regional capacity. Media CDN customers may also notice increased latencies. Initial traffic mitigations have yielded positive results for some Cloud customers. We have restored a large portion of Internet Edge peering capacity to reduce latency in the local Delhi metropolitan area. Since the last update, we have completed the augmentation of out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India. Following safety clearance, our team has accessed the damaged site and is continuing to restore additional capacity throughout this week. We have optimized capacity across network backbones to increase available headroom and augmented our Delhi user-facing backbone capacity. We will continue to closely monitor latency deviations and packet drops. We will provide our next update by Monday, 2026-06-29 at 17:00 PDT. **Symptoms** Customers may experience slightly elevated latency and non-optimal network routing into Google Cloud until the affected facility is fully restored. **Workaround** There is no workaround at this time.

9. 29 de junio de 2026 a las 23:06 UTCresolved

   **Summary** Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas experienced intermittent periods of elevated latency and possible packet loss. **Description** Traffic rerouting from the impacted Delhi facility caused a subset of Hybrid Connectivity, Virtual Private Cloud (VPC) and Media CDN customers to experience intermittent latency spikes as demand exceeded regional capacity. We completed the augmentation of out-of-region Internet Edge regional peering capacity in Chennai to provide additional load-balancing and redundancy to large ISPs in India. Service to a large portion of Internet Edge peering capacity has been restored to reduce latency in the local Delhi metropolitan area. We are now recovered and returned to normal service as of Friday, 2026-06-26 PDT. Following safety clearance, our team restored all lost capacity. We have restored capacity between Delhi-Chennai and Delhi-Mumbai and will continue to closely monitor latency deviations and packet drops. We thank you for your patience during the resolution of this issue. **Symptoms** The impacted customers may have experienced slightly elevated latency and non-optimal network routing into Google Cloud. **Workaround** None

1. 27 de febrero de 2026 a las 16:12 UTCresolved

   **Description** \ Between Friday, 2026-02-27, 04:36 and 06:45 PST, customers experienced increased error rates when accessing the Vertex Gemini API Global endpoint. The issue impacted API requests to multiple Gemini models. The incident also caused downstream impact to Dialogflow CX, Agent Assist, Google Cloud Support AI agent, and Customer Experience Agent Studio, which rely on Gemini APIs. Preliminary analysis indicates the issue was triggered by a recent configuration change. Service was fully restored after the configuration change was rolled back. We thank you for your patience while we worked on resolving the issue. **Symptom** \ Customers experienced increased error rates when sending API requests to impacted multiple Gemini models through the global endpoint.

2. 4 de marzo de 2026 a las 23:23 UTCresolved

   # Preliminary Incident Report We apologize for the inconvenience this service disruption may have caused. We would like to provide some information about this incident below. Please note, this information is based on our best knowledge at the time of posting and is subject to change as our investigation continues. A final Incident Report with preventative actions will be posted once our investigation is complete. If you have experienced impact outside of what is listed below, please reach out to Google Cloud Support using https://cloud.google.com/support. ## Date/Time of the Issue (All time US/Pacific) Incident Start: 27 February 2026 04:37 Incident End: 27 February 2026 06:35 Duration: 1 hour, 58 minutes ## Summary On Friday, 27 February 2026 at 04:37 US/Pacific, customers using Vertex AI Gemini API models (including Gemini 2.0, 2.5, and 3.0 previews) experienced increased error rates. Impacted services included Google Cloud Support, Agent Assist, the Vertex Gemini API and Dialogflow CX in US regions and the global endpoint for a duration of 1 hour and 58 minutes. This is not the level of quality and reliability we strive to offer you, and we are taking immediate steps to improve the platform’s performance and availability. ## Preliminary Root Cause This incident was caused by a configuration change to a safety filtering service that supports all Gemini models. This configuration change enabled a code path that interacted poorly with specific requests, leading to service disruption for the safety filtering service. This in turn led to customers seeing overload (429 and 503) errors for their queries. Google engineers have begun a full root cause analysis and will provide additional information once it is available. ## Remediation Google engineers were alerted to the service disruption via automated alert on Friday, 27 February 2026 04:54 US/Pacific and immediately started an investigation. Engineers identified the faulty configuration change for a safety filtering service and initiated a rollback to restore the previous stable configuration. Additionally, engineers added more capacity to the service. Full service restoration was confirmed by 06:35 US/Pacific as the rollback propagated and servers became healthy. ## Description of Impact On Friday, 27 February 2026 between 04:37 and 06:35 US/Pacific, customers accessing Vertex Gemini APIs may have experienced the following: - Affected Models: All Gemini versions were affected, including gemini-2.5-flash, gemini-2.5-flash-lite, gemini-2.5-pro, gemini-3.0-flash-preview, gemini-3.0-pro-preview, gemini-2.0-flash, gemini-2.0-flash-lite. - Error Experience: - PayGo Customers: Experienced primarily 429 Resource Exhausted errors. - Provisioned Throughput (PT) Customers: Received 503 Service Unavailable errors. - For PT customers, most errors stopped at 06:00. For PayGo customers, most errors stopped at 06:20. - Geographic Scope: Global endpoint, us-central1, us-east4, and other US regions were impacted.

3. 9 de marzo de 2026 a las 5:25 UTCresolved

   # Incident Report ## Summary On Friday, 27 February 2026 at 04:37 US/Pacific, customers using Vertex AI Gemini API models experienced increased error rates. Impacted services included Google Cloud Support, Agent Assist, Vertex Gemini API and Dialogflow CX in US regions and the global endpoint. The issue persisted for a duration of 1 hour and 58 minutes. This is not the level of quality and reliability we strive to offer you, and we have taken immediate steps to improve the platform’s performance and availability. ## Root Cause This incident was caused by a configuration change to a safety filtering service that supports all Gemini models. For some specific requests, this created code paths that eventually led to service disruptions and capacity loss for the safety filtering service. Consequently, customers encountered overload (429 and 503) errors for their queries, with some users reporting elevated error rates for specific models in US regions. ## Remediation and Prevention Google engineers were alerted to the issue via our automated monitoring system on Friday, 27 February 2026 04:54 US/Pacific and immediately started an investigation. Engineers identified the faulty configuration change and initiated a rollback to restore the previous stable configuration. Engineers also added more capacity to the service to stabilize it. Full service restoration was confirmed by 06:35 US/Pacific as the rollback propagated and servers became healthy. \ \ Google is committed to preventing a repeat of this issue and is taking the following actions: * Reinforcing rollout processes to include mandatory validation checkpoints. * Improving alerting systems to monitor critical dependencies more closely. ## ## Detailed Description of Impact On Friday, 27 February 2026 between 04:37 and 06:35 US/Pacific, customers accessing Vertex Gemini APIs may have experienced the following: * **Affected Models:** All Vertex AI Gemini API models were affected, including gemini-2.5-flash, gemini-2.5-flash-lite, gemini-2.5-pro, gemini-3.0-flash-preview, gemini-3.0-pro-preview, gemini-2.0-flash, gemini-2.0-flash-lite. * **Error Experience:** * **PayGo Customers:** Experienced primarily 429 Resource Exhausted errors. * **Provisioned Throughput (PT) Customers:** Received 503 Service Unavailable errors. * For PT customers, most errors stopped at **06:00**. For PayGo customers, most errors stopped at **06:20**. * **Geographic Scope:** Global endpoint, us-central1, us-east4, and other US regions were impacted.

1. 18 de julio de 2025 a las 15:54 UTCresolved

   We're currently experiencing elevated latency and error rates for several Cloud services in the us-east1 region, beginning at 7:06 AM PDT today, July 18, 2025. Our initial investigation points to a hardware infrastructure failure as the likely cause. We apologize for any disruption this may be causing. We'll provide an update with more details by 9:15 AM PDT today.

2. 18 de julio de 2025 a las 16:29 UTCresolved

   Our engineers have confirmed that us-east1-b is partially affected. All other zones in us-east1 are currently operating normally. Our engineers have recovered the failed hardware and are currently recovering the network control plane in the affected zones. We'll provide another update by 10:00 AM US/Pacific, July 18, 2025.

3. 18 de julio de 2025 a las 16:58 UTCresolved

   Our engineers have successfully recovered the network control plane in the affected us-east1 zones. We're seeing multiple services reporting full recovery, and product engineers are now validating the remaining services. We'll provide another update with more details by 10:30 AM US/Pacific, July 18, 2025.

4. 18 de julio de 2025 a las 17:32 UTCresolved

   Our engineers have successfully recovered the network control plane in the affected us-east1 zones. We're seeing multiple services reporting full recovery, and product engineers continue to validate the remaining services. We'll provide another update with more details by 11:00 AM US/Pacific, July 18, 2025.

5. 18 de julio de 2025 a las 18:03 UTCresolved

   The issue has been resolved for all affected products as of 2025-07-18 09:47 US/Pacific. From preliminary analysis, during a routine maintenance of our network in us-east1-b, we experienced elevated packet loss, causing service disruption in the zone. We will publish a full Incident Report with root cause once we have completed our internal investigations. We thank you for your patience while we worked on resolving the issue.

6. 18 de julio de 2025 a las 22:08 UTCresolved

   # Mini Incident Report We apologize for the inconvenience this service disruption/outage may have caused. We would like to provide some information about this incident below. Please note, this information is based on our best knowledge at the time of posting and is subject to change as our investigation continues. If you have experienced impact outside of what is listed below, please reach out to Google Cloud Support using https://cloud.google.com/support or to Google Workspace Support using help article https://support.google.com/a/answer/1047213. (All Times US/Pacific) **GCP Impact start and end time:** 18 July 2025 08:10 - 09:47 **Duration:** 1 hour 37 minutes **GWS Impact start and end time:** 18 July 2025 08:10 - 08:40 **Duration:** 30 minutes **Regions/Zones:** us-east1 **Description:** On Friday, 18 July 2025 08:10 US/Pacific multiple GCP and GWS products experienced elevated latencies and error rates in the us-east1 region for a duration of up to 1 hour and 37 minutes. Based on the preliminary analysis, the root cause of the issue is a procedural error during a planned hardware maintenance in one of our data centers in the us-east1 region. Our engineering team mitigated the issue by draining traffic away from the clusters and then restoring the affected hardware. Google will be completing a full incident report in the following days that will provide a full root cause and preventive actions. **Customer Impact:** The affected GCP and GWS products experienced elevated latencies and errors rates in the us-east1 region. **Affected Products:** **GCP :** AlloyDB for PostgreSQL, Apigee, Artifact Registry, Cloud Armor, Cloud Billing, Cloud Build, Cloud External Key Manager, Cloud Filestore, Cloud HSM, Cloud Key Management Service, Cloud Load Balancing, Cloud Monitoring, Cloud Run, Cloud Spanner, Cloud Storage for Firebase, Cloud Workflows, Database Migration Service, Dialogflow CX, Dialogflow ES, Google BigQuery, Google Cloud Dataflow, Google Cloud Dataproc, Google Cloud Storage, Google Cloud Support, Google Cloud Tasks, Google Compute Engine, Hybrid Connectivity, Media CDN, Network Telemetry, Private Service Connect, Secret Manager, Service Directory, Vertex AI Online Prediction, Virtual Private Cloud (VPC) **Workspace :** Gmail, Google Meet, Google Drive, Google Chat, Google Calendar, Google Groups, Google Doc/Editors, Google Voice **Google SecOps:** Google SecOps SOAR & Google SecOps

7. 22 de julio de 2025 a las 13:42 UTCresolved

   ## \# Incident Report ## \#\# Summary On Friday, 18 July 2025 07:50 US/Pacific, several Google Cloud Platform (GCP) and Google Workspace (GWS) products experienced elevated latencies and error rates in the us-east1 region for a duration of up to 1 hour and 57 minutes. **GCP Impact Duration:** 18 July 2025 07:50 \- 09:47 US/Pacific : 1 hour 57 minutes **GWS Impact Duration:** 18 July 2025 07:50 \- 08:40 US/Pacific : 50 minutes We sincerely apologize for this incident, which does not reflect the level of quality and reliability we strive to offer. We are taking immediate steps to improve the platform’s performance and availability. ## ## \#\# Root Cause The service interruption was triggered by a procedural error during a planned hardware replacement in our datacenter. An incorrect physical disconnection was made to the active network switch serving our control plane, rather than the redundant unit scheduled for removal. The redundant unit had been properly de-configured as part of the procedure, and the combination of these two events led to partitioning of the network control plane. Our network is designed to withstand this type of control plane failure by failing open, continuing operation. However, an operational topology change while the network control plane was in a failed open state caused our network fabric's topology information to become stale. This led to packet loss and service disruption until services were moved away from the fabric and control plane connectivity was restored. ## \#\# Remediation and Prevention Google engineers were alerted to the outage by our monitoring system on 18 July 2025 07:06 US/Pacific and immediately started an investigation. The following timeline details the remediation and restoration efforts: * **07:39 US/Pacific**: The underlying root cause (device disconnect) was identified and onsite technicians were engaged to reconnect the control plane device and restore control plane connectivity. At that moment, network failure open mechanisms worked as expected and no impact was observed. * **07:50 US/Pacific**: A topology change led to traffic being routed suboptimally, due to the network being in a fail open state. This caused congestion on the subset of links, packet loss, and latency to customer traffic. Engineers made a decision to move traffic away from the affected fabric, which mitigated the impact for the majority of the services. * **08:40 US/Pacific**: Engineers mitigated Workspace impact by shifting traffic away from the affected region. * **09:47 US/Pacific**: Onsite technicians reconnected the device, control plane connectivity was fully restored and all services were back to stable state. Google is committed to preventing a repeat of the issue in the future, and is completing the following actions: * Pause non-critical workflows until safety controls are implemented (complete). * Strengthen safety controls for hardware upgrade workflows by end of Q3 2025\. * Design and implement a mechanism to prevent control plane partitioning in case of dual failure of upstream routers by end of Q4 2025\. ## \#\# Detailed Description of Impact \#\#\# GCP Impact: Multiple products in us-east1 were affected by the loss of network connectivity, with the most significant impacts seen in us-east1-b. Other regions were not affected. The outage caused a range of issues for customers with zonal resources in the region, including packet loss across VPC networks, increased error rates and latency, service unavailable (503) errors, and slow or stuck operations up to loss of networking connectivity. While regional products were briefly impacted, they recovered quickly by failing over to unaffected zones. A small number (0.1%) of Persistent Disks in us-east1-b were unavailable for the duration of the outage: these disks became available once the outage was mitigated, with no customer data loss. \#\#\# GWS Impact: A small subset of Workspace users, primarily around the Southeast US, experienced varying degrees of unavailability and increased delays across multiple products, including Gmail, Google Meet, Google Drive, Google Chat, Google Calendar, Google Groups, Google Doc/Editors, and Google Voice.