Vários serviços registavam problemas na região europe-west2.
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos tendo um problema com vários serviços na Europa-west2 começando na segunda-feira, 2026-10-19 23:08 PDT. A nossa equipa de engenharia continua a investigar a questão. Nós forneceremos uma atualização até terça-feira, 2026-10-20 02:30 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Vários serviços do Google Cloud estão passando por erros elevados e falhas de rede intermitentes na região da Europa-west2. ** Solução Nenhuma por enquanto
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos tendo um problema com vários serviços na Europa-west2 começando na segunda-feira, 2026-10-19 23:08 PDT. A nossa equipa de engenharia continua a investigar a questão. Nós forneceremos uma atualização até terça-feira, 2026-10-20 04:00 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Vários serviços do Google Cloud estão experimentando erros elevados e falhas de rede intermitentes na região europe-west2. Nota: O Looker Studio não é impactado por esta falha. ** Solução Se possível, o cliente impactado pode tentar migrar sua carga de trabalho impactada para outro local disponível (zona ou região).
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos tendo um problema com vários serviços na Europa-west2 começando na segunda-feira, 2026-10-19 23:08 PDT. A nossa equipa de engenharia continua a investigar a questão. Nós forneceremos uma atualização até terça-feira, 2026-10-20 05:00 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Vários serviços do Google Cloud estão experimentando erros elevados e falhas de rede intermitentes na região europe-west2. Nota: O Looker Studio não é impactado por esta falha. ** Solução Se possível, o cliente impactado pode tentar migrar sua carga de trabalho impactada para outro local disponível (zona ou região).
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos tendo um problema com vários serviços na Europa-west2 começando na segunda-feira, 2026-10-19 23:08 PDT. Devido a um evento de energia, tivemos uma queda na zona Europa-Oeste-B. O evento de energia é atenuado. A mitigação parcial dos serviços de infra-estrutura será observada nos próximos 30 minutos e os restantes serviços serão ali atenuados. Nós forneceremos uma atualização até terça-feira, 2026-10-20 05:00 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Os serviços do Google Cloud não estão disponíveis na zona europe-west2-b; alguns serviços na região europe-west2 podem ter elevados erros e problemas de rede intermitentes. ** Solução Se possível, o cliente impactado pode tentar migrar sua carga de trabalho impactada para outro local disponível (zona ou região).
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos tendo um problema com vários serviços na Europa-west2 começando na segunda-feira, 2026-10-19 23:08 PDT. Um evento de potência causou uma queda na zona europe-west2-b. O evento de energia é atenuado. Estamos vendo a recuperação dos serviços e priorizando a recuperação das cargas de trabalho existentes. Os clientes podem ainda não ser capazes de criar novas cargas de trabalho. A recuperação total das cargas de trabalho existentes deve ser concluída, provisoriamente até terça-feira, 2026-10-20 06:00. Nós forneceremos uma atualização até terça-feira, 2026-10-20 06:00 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Os serviços do Google Cloud não estão disponíveis na zona europe-west2-b; alguns serviços na região europe-west2 podem ter elevados erros e problemas de rede intermitentes. ** Solução Se possível, o cliente impactado pode tentar migrar sua carga de trabalho impactada para outro local disponível (zona ou região).
- resolved
**Resumo** Vários serviços enfrentam problemas na região europe-west2. ** Descrição** Estamos vendo a recuperação de serviços para a maioria das cargas de trabalho na europa-west2 a partir de terça-feira, 2026-10-20 05:10 PDT. Nós forneceremos uma atualização até terça-feira, 2026-10-20 07:00 PDT com detalhes atuais. Pedimos desculpa a todos os que são afectados pela perturbação. ** Sintomas Os serviços do Google Cloud não estão disponíveis na zona europe-west2-b; alguns serviços na região europe-west2 podem ter elevados erros e problemas de rede intermitentes. ** Solução Se possível, o cliente impactado pode tentar migrar sua carga de trabalho impactada para outro local disponível (zona ou região).
- resolved
**Resumo** Vários serviços registavam problemas na região europe-west2. ** Descrição** O problema com produtos GCP impactados foi atenuado para a maioria dos clientes e acredita-se que esteja afetando atualmente um número muito pequeno de clientes e nossa equipe de engenharia está trabalhando nele. Se tiver dúvidas ou forem impactadas, por favor abra um caso com a Equipe de Suporte e trabalharemos com você até que este problema seja resolvido. Não serão fornecidas mais atualizações aqui. Publicaremos uma análise deste incidente assim que terminarmos a nossa investigação interna. Agradecemos a sua paciência enquanto trabalhamos para resolver o problema. ** Sintomas Os serviços do Google Cloud não estavam disponíveis na zona europe-west2-b; alguns serviços na região europe-west2 podem ter tido erros elevados e problemas de rede intermitentes. ** Solução Nenhum como a questão foi atenuada.
- resolved
# # Relatório preliminar de incidentes Reconhecemos que os serviços do Google Cloud são críticos para sua organização, e sinceramente pedimos desculpas pela interrupção que este incidente pode ter causado ao seu negócio. Estamos trabalhando para abordar a causa raiz e impedir que isso ocorra no futuro. Por favor, note que esta informação se baseia no nosso melhor conhecimento no momento da publicação e está sujeita a alterações à medida que a nossa investigação continua. Um relatório final de incidentes com ações preventivas será publicado assim que nossa investigação estiver concluída. Se você teve impacto fora do que está listado abaixo, entre em contato com o Google Cloud Support usando [**https\://cloud.google.com/support**](https://cloud.google.com/support). # # Data/Hora da questão Início do incidente: 19 Out 2026 23:00 US/Pacífico / 20 Out 2026 07:00 BST Fim do incidente: 20 out 2026 05:10 US/Pacífico / 20 out 2026 13:10 BST Duração: 6 horas, 10 minutos # # Resumo Na segunda-feira, 19 de outubro de 2026 (terça-feira, 20 de outubro BST), vários serviços da plataforma Google Cloud na região europe-west2 experimentaram interrupções de serviço, taxas de erro elevadas, prazos de programação de aplicativos (API) e latência de processamento por uma duração de 6 horas e 10 minutos. A interrupção foi desencadeada por uma interrupção de energia elétrica na instalação de datacenter hospedando zona de disponibilidade europe-west2-b, que temporariamente levou servidores host físicos, hardware de roteamento de rede e sistemas de armazenamento offline. Esta situação provocou subsequentemente uma falha secundária e uma redução dos atrasos nas infra-estruturas regionais não afectadas. # # Causa preliminar raiz O incidente foi desencadeado quando ocorreu uma ruptura da rede elétrica na unidade de datacenter hospedando a zona de disponibilidade europa-west2-b. Para manter a energia contínua durante a interrupção, a transferência automática para sistemas de backup de instalação foi desencadeada imediatamente. A carga da instalação foi transferida para os bancos de baterias UPS durante a sequência de arranque de geradores diesel de emergência no local. O sistema de automação Programmable Logic Controller (PLC) (PLCs primários e de backup) falhou ao iniciar as operações lógicas de inicialização/transferência automática dos geradores, impedindo que os geradores de backup assumissem a carga. Quando as reservas de bateria UPS foram esgotadas, servidores host físicos, tecido de comutação de rede e arrays de armazenamento locais dedicados à europa-west2-b perderam energia e ficaram offline. A sequência de eventos que levaram ao impacto do cliente foi a seguinte: * Às 22:53 US/Pacific (20 de outubro de 06:53 BST), uma ruptura de energia elétrica ocorreu na instalação de datacenter hospedando a zona de disponibilidade europe-west2-b, e uma falha de inicialização PLC (Controlador Lógico Programável) impediu geradores de emergência da instalação de assumir a carga elétrica. A carga das instalações continuou a ser suportada pelos bancos de baterias UPS até que as baterias foram esgotadas, começando às 23:00 US/Pacífico (20 out, 07:00 BST). * Quando os servidores host físicos, infraestrutura de armazenamento local e hardware de agregação de rede na europa-west2-b perderam energia, fez com que instâncias, réplicas de banco de dados e nós de trabalhadores naquela zona se tornassem imediatamente inalcançáveis. * Mecanismos regionais de roteamento de tráfego e aplicativos do cliente iniciaram failover automatizado para infraestrutura disponível em zonas de disponibilidade adjacentes dentro da região. * Chamadas de procedimentos remotos de zonas cruzadas de aviões regionais de controle de serviços direcionados para metadados e componentes de catálogo na zona offline encontraram timeouts, causando paradas iniciais de submissão de tarefas e picos de latência da API. * O influxo repentino de execuções de consultas redirecionadas, falhas de banco de dados de alta disponibilidade, e cargas de trabalho saturadas disponíveis saturadas slots de computação e capacidade de processamento em outras zonas de disponibilidade, criando filas de admissão elevadas, falhas de banco de dados atrasadas, e erros intermitentes de API 500 e 503 em toda a região. Os engenheiros do Google começaram uma análise completa da causa raiz (RCA) e fornecerão informações adicionais uma vez que esteja disponível. # # Remediação Engenheiros da Google foram alertados para a interrupção através de sistemas de monitoramento automatizado e sondadores em 23:08 EUA/Pacífico em 19 de outubro (20 de outubro de 07:08 BST), que detectaram elevadas razões de erro API, timeouts de submissão de trabalho e perda de acessibilidade de infraestrutura na Europa-west2-b. Equipas de engenharia imediatamente mobilizadas para isolar a infra-estrutura afectada e iniciar a recuperação: * ** Isolamento do tráfego: ** Os engenheiros do Google isolaram a zona de disponibilidade off-line (europe-west2-b) ajustando o roteamento do serviço regional para longe da infra-estrutura afetada, impedindo que as solicitações de clientes interzonais fossem sincronizadas com os objetivos offline. * ** Reprioritização de carga de trabalho e Salvaguardas de Recursos:** Os engenheiros ajustaram as alocações de agendamento e os limites de capacidade em toda infraestrutura sem impacto para priorizar reservas de clientes ativos, reduzir a contenção de recursos em slots de execução e aliviar os atrasos de fila para cargas de trabalho regionais. * Restauração da Grade de Energia:** Engenheiros de instalações no local realizaram uma restauração graciosa de uma alimentação de energia de utilidade estável, uma vez que o fornecimento de utilidade estava de volta, dentro de 1 hora. Depois disso, eles focaram e completaram uma reinicialização e testaram os controladores de automação do gerador de backup de emergência para restaurar a energia da instalação. * ** Reactivação progressiva da infra-estrutura: ** Engenheiros do Google reiniciaram sistematicamente a infraestrutura e serviços do Google Cloud. * ** Re-admissão de tráfego controlado: ** Uma vez verificada a integridade do sistema de saúde e armazenamento, os engenheiros executaram uma re-admissão gradual e controlada do tráfego de volta à zona europe-west2-b, permitindo que os atrasos acumulados de trabalho se tornassem claros. Por volta das 05:10 US/Pacific na terça-feira, 20 out(13:10 BST), a disponibilidade de serviço havia recuperado para a grande maioria das cargas de trabalho dos clientes, e a resolução para a maioria dos clientes em todos os serviços da Plataforma da nuvem do Google na região foi confirmada. Após a recuperação de uma pequena cauda de cargas de trabalho isoladas remanescentes, a notificação de encerramento do incidente foi afixada por 07:03 US/Pacific (15:03 BST). # # Descrição do Impacto Entre segunda-feira, 19 de outubro de 2026, 23:00 US/Pacific (terça-feira, 20 de outubro de 2026, 07:00 BST) e terça-feira, 20 de outubro de 2026, 05:10 US/Pacific (13:10 BST), os clientes que utilizavam serviços da plataforma Google Cloud na região europe-west2 experimentaram interrupções de serviço em duas fases consecutivas, durando uma duração total de 6 horas, 10 minutos. Durante a fase inicial das 23:00 às 04:29 US/Pacific (07:00 às 12:29 BST) (duração de 5 horas, 29 minutos), os clientes experimentaram elevadas taxas de erro, intervalos de API e atrasos de processamento até que a maioria dos serviços do Google Cloud Platform se recuperou. Após a restauração do serviço de plataforma, algumas cargas de trabalho do cliente em execução em instâncias do Compute Engine experimentaram uma cauda de recuperação mais longa. Por volta de 04:46 US/Pacific (12:46 BST) nova criação de máquina virtual retomada e em 05:10 US/Pacific (13:10 BST) mais de 99% das máquinas virtuais de motor de computação estavam em um estado saudável. Quaisquer clientes restantes que estivessem tendo problemas com a Máquina Virtual foram direcionados para registrar um problema de suporte ao cliente de acordo com o procedimento normal. Embora a queda de energia física tenha sido isolada estritamente às instalações de datacenter na Europa-west2-b, alguns clientes que executam cargas de trabalho em zonas não afectadas (europe-west2-a e europe-west2-c) ou nas arquitecturas regionais também tiveram um impacto inesperado. As causas primárias foram 1\) picos instantâneos de demanda na capacidade de computação não impactada e 2\) dependências de validação do plano de controle síncrono através dos limites zonais. Produtos afetados incluídos: BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Disco Persistente Regional e Cloud SQL. Esses serviços experimentaram problemas inesperados de degradação e failover impulsionados pela exaustão súbita da capacidade de computação da demanda crescente, e tempo limite de API do plano de controle aguardando validações da zona offline. As cargas de trabalho e os recursos mantidos inteiramente na Europa-west2-b tornaram-se inalcançáveis. Os serviços de armazenamento de dados com capacidade de failover, como Cloud SQL, AlloyDB, Memorystore for Redis e Cloud Bigtable falharam em zonas próximas sem impacto durante a falha europe-west2-b. Os serviços multizonais e regionais que abrangeram toda a região europe-west2 experimentaram latência elevada, erros transitórios de API (como erros HTTP 500 e 503) e a admissão de tarefas em filas de espera como tráfego failover concentrado em recursos regionais descompactados e chamadas interzonais para componentes offline cronometrados. As operações de gravação de armazenamento na região experimentaram uma taxa de erro transitória durante o período inicial de failover, e as filas de admissão de consultas regionais temporariamente alcançaram o pico antes de rapidamente subsidiarem como capacidade reequilibrada. Os seguintes serviços da Google Cloud Platform tiveram impacto: * AlloyDB para PostgreSQL * Apigee * Serviço de Transferência de Dados BigQuery * Cloud Data Fusion * Loja de arquivos em nuvem * Cloud Firestore * Balanceamento de carga em nuvem * Cloud Memorystore * Nuvem NAT * Cloud Run * Cloud Spanner * Postos de trabalho em nuvem * 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 (Security Information and Event Management \[SIEM\] e Security Orchestration, Automation, and Response \[SOAR\]) * Olhador (núcleo do Google Cloud) * Looker Studio * Gerenciado fluxo de ar (Google Cloud Composer) * Serviço gerenciado para Apache Kafka * Memorystore para Memcached * Memorystore para Redis * Memorystore para Redis Cluster * Memorystore para Valkey * Centro de Conectividade de Rede * Disco Persistente * Serviço Privado Connect * Discurso-a-texto * Virtual Private Cloud (VPC) * Motor VMWare
- resolved
## Incident Report ### **Summary** On Monday, 19 Oct 2026 (Tuesday, 20 Oct BST), a data center facility that hosts europe-west2-b, experienced an external electrical power disruption. This resulted in service unavailability for workloads located in this zone. As traffic was redirected to alternative cloud regions or unaffected zones within europe-west2 cloud region, these workloads experienced transient latency and elevated errors affecting services across europe-west2. The primary impact was mitigated after 6 hours 8 minutes. ### **Root Cause** **Facility architecture and background:** The data center facility in the UK region hosts Cloud clusters serving the europe-west2-b zone, which form part of the multi-zonal europe-west2 Cloud region. The site relies on a 2N utility power architecture—meaning the facility has complete duplicate power paths for every critical load—backed by a central high-voltage generator bank managed by a dual-redundant Programmable Logic Controller (PLC). Primary utility power is supplied to the facility via two independent feeders (A and B), supplemented by a standby utility connection configured for manual campus-wide transfer during maintenance operations or emergency events. The two high-voltage primary feeders terminate at separate primary intake switchboards capable of closed-loop operation if either board is taken offline. Switching between the primary and standby utility providers utilizes open transitions and key interlocks to prevent parallel connections across sources. Static Uninterruptible Power Supply (UPS) battery systems provide 5 minutes of autonomous runtime. This bridge power ensures uninterrupted operation while the PLC detects utility undervoltage events, initiates diesel generator startup, synchronizes the generators, and transfers the site load. Prior to the utility disruption, the facility had been placed in a temporary single-feed (1N) bridged maintenance posture on the primary utility. Circuit breaker feeder B was physically opened and key-interlocked (Locked Out Tagged Out) to allow for corrective repairs following issues identified during a quarterly generator load test on 14 Oct 2026. Consequently, primary utility feed A was supporting the total critical load while repairs were conducted on the B feeder pathway. **Root Cause:** On Monday, 19 Oct 2026 at 22:53 US/Pacific (Tuesday, 20 Oct 06:53 BST), the primary utility provider experienced an outage on primary utility feed A, caused by an external underground cable fault on the utility network outside the data center facility. When the primary utility feed A was lost, the facility’s generator plant failed to receive a signal to automatically start and take critical load due to a design voltage-sensing and misconfiguration in the PLCs. The facility's static UPS battery banks carried the critical load as designed until their battery reserves depleted resulting in a complete power loss across data halls. The investigation of the PLC configuration identified the root cause as a misconfiguration of the PLC logic that did not verify both an undervoltage condition and physical breaker position for both utility feeders. Instead, the PLC undervoltage sensing inputs were wired upstream (line side) of the isolated utility feed B breaker. The PLC was programmed to verify whether voltage was present on the feeder before commanding a generator start. As the utility feed B remained energized upstream, both PLCs sensed live upstream voltage on the disconnected path. As a result, the PLC logic indicated that a healthy utility source was available, even though the primary and secondary distribution feeds were de-energized, and did not issue a start command to the generator plant.; The onsite facilities team attempted to execute a remote load transfer via the PLC; however, the system inhibited the action. Recognizing that the UPS battery reserves would be exhausted before further remote operations could be resolved, the team transferred the facility load to the standby utility source, restoring the critical load that was lost once batteries depleted during this process. Once utility power was restored via the standby utility source, and UPS batteries started recharging, the onsite facility teams and OEM vendors reconfigured and validated PLC functionality on both undervoltage and breaker status. After the power loss was initially detected, Google engineers began work to mitigate failover failures and prepare service recovery. Upon restoration of the utility source, UPS and generator capabilities, they began the process to re-enable services in europe-west2-b. ### Remediation and Prevention The sequence of events leading to customer impact was as follows: * **19 Oct 22:53 US/Pacific (20 Oct BST 06:53 BST) -** An electrical power disruption occurred at the data center facility hosting availability zone europe-west2-b, and a PLC (Programmable Logic Controller) startup fault prevented facility emergency generators from assuming the electrical load. Facility load continued to be supported by UPS battery banks until the batteries were depleted. * **19 Oct 23:00 US/Pacific (20 Oct 07:00 BST)** **Impact start -** As battery backups were exhausted, physical host servers, local storage infrastructure, and network aggregation hardware in availability zone europe-west2-b lost power, causing instances, database replicas, and worker nodes in that zone to become immediately unreachable. * **19 Oct 23:04 US/Pacific (20 Oct 07:04 BST) -** Google engineers were alerted to the disruption via automated monitoring systems and probers, which detected elevated API error ratios, job submission timeouts, and loss of infrastructure reachability in zone europe-west2-b. Engineering teams immediately mobilized to isolate the affected infrastructure and commence recovery. * **19 Oct 23:09 US/Pacific (20 Oct 07:09 BST) -** Regional traffic-routing mechanisms and client applications initiated automated failover toward available infrastructure in adjacent availability zones within the region. * Cross-zone remote procedure calls from regional service control planes directed to metadata and catalog components in the offline zone encountered timeouts, causing initial job submission stalls and API latency spikes. * The sudden influx of redirected query executions, high-availability database failovers, and compute workloads saturated available compute slots and processing capacity in other availability zones, creating elevated admission queues, delayed database failover completions, and intermittent 500 and 503 API errors across the region. * **Traffic Isolation:** Google engineers isolated the offline availability zone (europe-west2-b) by adjusting regional service routing away from the affected infrastructure, preventing cross-zone client requests from timing out against offline endpoints. * **Workload Reprioritization and Resource Safeguards:** Engineers adjusted scheduler allocations and capacity limits across unimpacted infrastructure to prioritize active customer reservations, reduce resource contention on execution slots, and relieve queue backlogs for regional workloads. * **19 Oct 23:54 US/Pacific (20 Oct 07:54 BST) Utility Power Restoration** **\-** Power supply from the standby utility source was restored and power restoration to the data hall began. * **20 Oct 00:20 US/Pacific (08:20 BST) Datahall Power Restoration** **\-** Utility power was re-established to the datahalls. Mains utility power normalized; power feed to data hall verified. Following this, the site operations and engineering teams focused on and completed a reset and tested the emergency backup generator automation controllers to restore facility power. * **20 Oct 00:40 US/Pacific (08:40 BST)** **\-** Clusters began to recover, cluster manager systems started rescheduling compute jobs. * **20 Oct 00:45 US/Pacific (08:45 BST) \-** Network devices were back online. * **20 Oct 00:50 US/Pacific (08:50 BST) \-** Due to the immediacy of power loss, storage devices with unclean shutdowns began recovery. Responders recognized this and chose not to restore services that would otherwise make this worse. Because of the large volume of storage devices involved, this process required a substantial period to finish prior to restoring service to customers. * **20 Oct 03:13 US/Pacific (11:06 BST)** **\-** Power redundancy was verified and the storage infrastructure was sufficiently restored to prepare the initiation of controlled traffic re-admission. The remaining storage systems continued recovery operations. * **20 Oct 03:45 US/Pacific (11:45 BST) Controlled Traffic Re-admission** **\-** Once system health and storage integrity were verified, engineers executed gradual, controlled traffic re-admission back to zone europe-west2-b allowing accumulated job backlogs to clear smoothly. * **20 Oct 04:11 US/Pacific (12:11 BST)** **\-** Google Cloud Platform services and APIs were made fully available to customers. Some Google Compute Engine virtual machines were still not yet available. * **20 Oct 04:29 US/Pacific (12:29 BST) \-** Regional services and backend compute management systems were fully undrained, marking the end of core platform-level disruption. * **20 Oct 05:08 US/Pacific (13:08 BST) Majority Workload Recovery** **\-** GCE virtual machines were 99.5% operational and healthy, and creating new VMs was fully supported. Service availability was restored for most customer workloads, with resolution confirmed for the majority of users across Google Cloud Platform services in the region. Following the recovery of a small tail of remaining isolated workloads, the closure notification for the incident was posted by 07:03 US/Pacific (15:03 BST). Google is committed to preventing a repeat of this issue in the future and is completing the following actions: **Data Center Action Items:** * Restoration of normal utility configuration (both A & B feeds) * Utility provider to locate the damaged cable fault, using low-frequency radar penetration testing procedures. **\[Completed 26 Oct\]** * Utility provider to send on-site engineers to repair the cable fault and restore the impacted primary utility feed A source. **\[Estimated Completion Date 30 Oct\]** * Onsite Operations teams with a controlled method of procedure (MOP) to transfer the facility to its primary utility source (feeds A and B) from standby utility feed through coordinated switching with the utility provider **\[Estimated Completion Date 31 Oct\]** * Generator confidence testing * Full generator load transfer tests with utility power cutover of the active utility feed. Test automatic startup of generators through PLC signals within the backup battery timer and detailed review of backup procedures **\[Completed on 20 Oct and 26 Oct (full critical load transfer test including updated EOPs)\]** * Full generator load transfer tests in coordination with the primary utility source feeds (A and B) after restoration work completed by the primary utility provider. **\[Estimated Completion Date 31 Oct\]** * PLC configuration fix * Reconfigured and validated the PLC after the outage on 20 Oct and then again on 26 Oct **\[Completed 26 Oct\]** * Google engineers to work in collaboration with the facility vendor teams to perform a comprehensive PLC code review and system resiliency to multiple failure scenarios. **\[Estimated Completion Date (prior to generator transfer test) estimated 31 Oct\]** * Validate PLC telemetry once primary utility feed A and B lineup is restored. **\[Estimated Completion Date 31 Oct\]** * Validate global PLC configurations at all global sites with similar topologies and PLC manufacturers, to ensure confidence in automatic generator starts. **\[Estimated Completion Date 15 Nov\]** * Emergency Operating Procedures (EOP) documentation update: * Comprehensive update to the EOP for site’s response to unexpected loss of active utility source. Update includes \- manual steps to attempt to restore active utility feed, manual restart of generators and manual transfer to other utility sources within the UPS battery run time. **\[Completed 26 Oct\]** * Ensure updated EOP is practiced twice per shift by on-site facility team. **\[Completed 24 Oct and checked with Google DC Operations daily\]** * Strengthen change management: * Freeze planned maintenance activities at other sites with similar topologies, and implement elevated approvals and reviews for data center configuration changes which are outside their standard designs. **\[Estimated Completion Date 30 Oct\]** **Cloud Service Action Items:** * **Communications Enhancement:** Bolster notification speed by developing an automated alert-to-communication mechanism for location-impacting incidents. * **Platform Testing:** Expand platform-wide testing outcomes for infrastructure-level events. ### **Detailed Description of Impact** Between Monday, 19 Oct 2026, 23:00 US/Pacific (Tuesday, 20 Oct 2026, 07:00 BST) and Tuesday, 20 Oct 2026, 05:08 US/Pacific (13:08 BST), customers utilizing Google Cloud Platform services in the europe-west2 region experienced service disruptions across two consecutive phases, lasting a total duration of 6 hours, 08 minutes. During the initial phase from 23:00 to 04:29 US/Pacific (07:00 to 12:29 BST) (duration 5 hours, 29 minutes), customers experienced unavailability of zone-scoped resources in products, including: * **Compute Engine** \- VM instances, zonal MIGs, unmanaged instance groups, zonal NEGs, sole-tenant node groups, zonal reservations, target instances, zonal API operations. * **Persistent Disk / Hyperdisk** \- Zonal PD, zonal Hyperdisk, Hyperdisk storage pools, instant snapshots. * **GKE \-** Zonal clusters (control plane), node pool nodes in \-b, PVs on zonal disks. * **Cloud SQL \-** Non-HA instances, read replicas in \-b. * **AlloyDB \-** Basic (non-HA) primaries in \-b. * **Bigtable \-** Single-cluster instances in \-b. * **Other products with affected zonal resources:** Cloud Batch, Cloud Build, Cloud Storage, Cloud Workstations, Composer, Dataproc, Filestore, Managed Lustre, Migrate to VMs, NetApp Volumes, Pub/Sub Lite, Vertex AI Workbench, VMware Engine. The unavailability of those resources scoped to a zone that undergoes disruption is working within the design of a zonally-scoped system. Requests made to these resulted either in a timeout or error code during the disruption. Any workloads and resources hosted entirely within europe-west2-b became unreachable due to this event. Google Compute Engine's zonal resources such as VMs require customers to provision failover or cross-zone recovery resources if needed, and to set up a recovery mechanism that matches their needs. Some failovers were unsuccessful due to capacity constraints and difficulty in replicating the underlying storage mechanism. Following platform service restoration, some customer workloads running on Compute Engine instances as well as products that rely on Compute Engine experienced a longer recovery. By 04:46 US/Pacific (12:46 BST) new Virtual Machine creation resumed and by 05:08 US/Pacific (13:08 BST) over 99% of Compute Engine Virtual Machines were in a healthy state. Any remaining customers that were experiencing Virtual Machine problems were directed to file a customer support case as per normal procedure. While the physical power outage was isolated strictly to data center facilities in zone europe-west2-b, some customers running workloads in unimpacted zones (europe-west2-a and europe-west2-c) or across regional architectures also experienced unexpected impact. The primary causes of impact outside of zone europe-west2-b were: 1\) Instantaneous demand surges on neighboring zones (a and c) and 2\) Control-plane dependencies across zonal boundaries Affected products included: AlloyDB, Apigee Infra and Apigee Edge, BigQuery, Cloud Dataflow, Cloud Pub/Sub, Cloud SQL, Google Compute Engine, Google Kubernetes Engine, Looker, Regional Persistent Disk, Vertex AI Prediction, and Cloud Speech-to-Text. These services experienced unexpected degradation and failover issues driven by sudden compute capacity exhaustion from surging demand, and control-plane API timeouts. Customers would have experienced the inability to create, update, or delete some regional resources during this period. This was not a full regional control-plane outage, but certainly a degraded state. Multi-zonal and regional services that spanned across the europe-west2 region experienced elevated latency, transient API errors (such as HTTP 500 and 503 errors), and task admission queuing as failover traffic concentrated onto unimpacted regional resources and cross-zone calls to offline components timed out. Storage write operations in the region experienced a transient error rate during the initial failover period, and regional query admission queues temporarily peaked before rapidly subsiding as capacity re-balanced. We did not identify any impact of the outage outside of the europe-west2 region. The following Google Cloud Platform services experienced impact within europe-west2: * AlloyDB for PostgreSQL * Apigee * BigQuery Data Transfer Service * Cloud Data Fusion * Cloud Filestore * Cloud Firestore * Cloud Load Balancing * 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 (Security Information and Event Management \[SIEM\] and Security Orchestration, Automation, and Response \[SOAR\]) * Looker (Google Cloud core) * Looker Studio * Managed Airflow (Google Cloud Composer) * Managed Service for Apache Kafka * Memorystore for Memcached * Memorystore for Redis * Memorystore for Redis Cluster * Memorystore for Valkey * Network Connectivity Center * Persistent Disk * Private Service Connect * Speech-to-Text * Virtual Private Cloud (VPC) * VMWare engine ----------
Traduzido automaticamente da atualização oficial do incidente.