Mai multe servicii se confruntau cu probleme în regiunea europe-vest2.
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Ne confruntăm cu o problemă cu servicii multiple în Europa-Vest2 începând de luni, 2026-10-19 23:08 PDT. Echipa noastră de inginerie continuă să investigheze problema. Vom furniza o actualizare până marţi, 2026-10-20 02:30 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Mai multe servicii Google Cloud se confruntă cu erori ridicate și eșecuri intermitente ale rețelei în regiunea Europa-Vest2. **Lucrarea** Nici unul pentru moment
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Ne confruntăm cu o problemă cu servicii multiple în Europa-Vest2 începând de luni, 2026-10-19 23:08 PDT. Echipa noastră de inginerie continuă să investigheze problema. Vom oferi o actualizare până marţi, 2026-10-20 04:00 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Multiple servicii Google Cloud se confruntă cu erori ridicate și eșecuri intermitente ale rețelei în regiunea Europa-Vest2. Notă: Looker Studio nu este afectat de această pană. **Lucrarea** Dacă este posibil, clientul afectat poate încerca să migreze volumul lor de muncă afectat într-o altă locație disponibilă (zonă sau regiune).
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Ne confruntăm cu o problemă cu servicii multiple în Europa-Vest2 începând de luni, 2026-10-19 23:08 PDT. Echipa noastră de inginerie continuă să investigheze problema. Vom oferi o actualizare până marţi, 2026-10-20 05:00 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Multiple servicii Google Cloud se confruntă cu erori ridicate și eșecuri intermitente ale rețelei în regiunea Europa-Vest2. Notă: Looker Studio nu este afectat de această pană. **Lucrarea** Dacă este posibil, clientul afectat poate încerca să migreze volumul lor de muncă afectat într-o altă locație disponibilă (zonă sau regiune).
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Ne confruntăm cu o problemă cu servicii multiple în Europa-Vest2 începând de luni, 2026-10-19 23:08 PDT. Din cauza unui eveniment de putere am suferit o pană în zona europe-vest2-b. Evenimentul de putere este atenuat. Diminuarea parțială a serviciilor de infrastructură va fi observată în următoarele 30 de minute, iar serviciile rămase vor fi atenuate după aceea. Vom oferi o actualizare până marţi, 2026-10-20 05:00 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Serviciile Google Cloud nu sunt disponibile în zona europe-vest2-b; unele servicii din regiunea Europa-Vest2 pot experimenta erori ridicate și probleme intermitente de rețea. **Lucrarea** Dacă este posibil, clientul afectat poate încerca să migreze volumul lor de muncă afectat într-o altă locație disponibilă (zonă sau regiune).
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Ne confruntăm cu o problemă cu servicii multiple în Europa-Vest2 începând de luni, 2026-10-19 23:08 PDT. Un eveniment de putere a cauzat o pană în zona europe-vest2-b. Evenimentul de putere este atenuat. Vedem recuperarea serviciilor și prioritizăm recuperarea volumului de muncă existent. S-ar putea ca clienții să nu poată crea încă noi locuri de muncă. Recuperarea completă a volumului de muncă existent ar trebui să fie finalizată, în mod provizoriu până marţi, 2026-10-20 06:00. Vom oferi o actualizare până marţi, 2026-10-20 06:00 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Serviciile Google Cloud nu sunt disponibile în zona europe-vest2-b; unele servicii din regiunea Europa-Vest2 pot experimenta erori ridicate și probleme intermitente de rețea. **Lucrarea** Dacă este posibil, clientul afectat poate încerca să migreze volumul lor de muncă afectat într-o altă locație disponibilă (zonă sau regiune).
- resolved
** Summary ** Mai multe servicii se confruntă cu probleme în regiunea europe-vest2. ** Descriere ** Vedem recuperarea serviciilor pentru majoritatea volumului de muncă în Europa-Vest2 începând de marţi, 2026-10-20 05:10 PDT. Vom oferi o actualizare până marţi, 2026-10-20:00 PDT cu detalii curente. Ne cerem scuze tuturor celor afectaţi de întrerupere. ** Simptome ** Serviciile Google Cloud nu sunt disponibile în zona europe-vest2-b; unele servicii din regiunea Europa-Vest2 pot experimenta erori ridicate și probleme intermitente de rețea. **Lucrarea** Dacă este posibil, clientul afectat poate încerca să migreze volumul lor de muncă afectat într-o altă locație disponibilă (zonă sau regiune).
- resolved
** Summary ** Mai multe servicii se confruntau cu probleme în regiunea europe-vest2. ** Descriere ** Problema cu produsele GCP afectate a fost atenuată pentru majoritatea clienților și se crede că afectează în prezent un număr foarte mic de clienți și echipa noastră de inginerie lucrează la aceasta. Dacă aveți întrebări sau sunt afectate, vă rugăm să deschideți un caz cu echipa de sprijin și vom lucra cu tine până când această problemă este rezolvată. Nu se vor mai furniza actualizări aici. Vom publica o analiză a acestui incident după ce terminăm investigaţia internă. Vă mulţumim pentru răbdare în timp ce lucrăm la rezolvarea problemei. ** Simptome ** Serviciile Google Cloud nu au fost disponibile în zona europe-vest2-b; unele servicii din regiunea Europa-Vest2 ar putea suferi erori ridicate și probleme intermitente de rețea. **Lucrarea** Niciunul dintre acestea nu a fost atenuat.
- resolved
## Raport preliminar de incident Recunoastem ca serviciile Google Cloud sunt esentiale pentru organizatia dumneavoastra si ne cerem sincer scuze pentru intreruperea pe care acest incident poate sa o fi cauzat afacerii dumneavoastra. Ne străduim să abordăm cauza fundamentală şi să prevenim acest lucru în viitor. Vă rugăm să rețineți, aceste informații se bazează pe cele mai bune cunoștințe ale noastre la momentul postării și sunt supuse schimbării pe măsură ce ancheta noastră continuă. Un raport final de incident cu acţiuni preventive va fi postat după finalizarea investigaţiei noastre. Dacă ați avut un impact în afara celor enumerate mai jos, vă rugăm să accesați Google Cloud Support folosind [**https\://cloud.google.com/support**](https://cloud.google.com/support). ## Data/ora emisiunii Incident Start:19 octombrie 2026 23:00 US/Pacific / 20 octombrie 2026 07:00 BST Sfârşitul incidentului: 20 octombrie 2026 05:10 US/Pacific / 20 octombrie 2026 13:10 BST Durata: 6 ore, 10 minute ## Rezumat Luni, 19 octombrie 2026 (marți, 20 octombrie BST), mai multe servicii Google Cloud Platform în regiunea Europa-Vest2 au suferit întreruperi ale serviciilor, rate ridicate de eroare, termene de programare a aplicațiilor (API) și latență de procesare pentru o perioadă de 6 ore și 10 minute. Perturbarea a fost declanșată de o întrerupere a energiei electrice la centrul de date care găzduiește zona de disponibilitate Europa-west2-b, care a luat temporar servere gazdă fizică, hardware de rutare a rețelei și sisteme de stocare offline. Acest lucru a cauzat ulterior întârzieri secundare în ceea ce privește infrastructura regională fără impact. ## Preliminary Root Cause Incidentul a fost declanşat când a avut loc o întrerupere a reţelei electrice la centrul de date care găzduia zona de disponibilitate Europa-west2-b. Pentru a menține puterea continuă în timpul întreruperii, transferul automat la sistemele de alimentare de rezervă a instalației a fost declanșat imediat. Încărcătura instalației a fost transferată la bateriile de alimentare cu energie electrică (UPS) fără întrerupere în timpul secvenței de pornire a generatoarelor diesel de urgență la fața locului. Sistemul de automatizare Logic Controller programabil (PLC) (atât PLC primar cât şi de rezervă) nu a iniţiat operaţiunile logice de pornire/transfer automat ale generatoarelor, împiedicând generatoarele de rezervă să-şi asume sarcina. Atunci când rezervele de baterii UPS au fost epuizate, servere de gazda fizica, tesatura de comutare a retelei, si retele de stocare locale dedicate Europei-Vest2-B a pierdut puterea si a plecat offline. Secvența evenimentelor care au condus la impactul asupra clienților a fost următoarea: * La 22:53 US/Pacific (20 octombrie, 06:53 BST), o întrerupere a energiei electrice a avut loc la unitatea de datecenter care găzduiește zona de disponibilitate europe-west2-b, precum și o eroare PLC (Programable Logic Controller) pornire a împiedicat generatoarele de urgență ale instalației să-și asume sarcina electrică. Încărcătura instalației a continuat să fie susținută de băncile de baterii UPS până la epuizarea bateriilor, începând cu ora 23:00, SUA/Pacific (20 octombrie, 07:00 BST). * Atunci când serverele gazdă fizice, infrastructura de stocare locală și hardware-ul de agregare a rețelei în Europa-west2-b au pierdut puterea, au cauzat cazuri, replici de baze de date și noduri de muncă în acea zonă să devină imediat inaccesibile. * Mecanismele regionale de direcţionare a traficului şi aplicaţiile clienţilor au iniţiat o esecare automată către infrastructura disponibilă în zonele de disponibilitate adiacente din regiune. * Cross-zona de proceduri de la distanță apeluri de la avioane regionale de control serviciu direcţionate către metadate şi componente de catalog în zona offline intalnit timeouts, cauzand standuri de depunere de locuri de muncă iniţiale şi API latency Spikes. * Afluxul brusc de execuții de interogare redirecționate, eșecuri de baze de date de înaltă disponibilitate, și volum de muncă calculat saturate sloturi disponibile și capacitate de procesare în alte zone de disponibilitate, crearea de cozi de admisie ridicate, failover de baze de date întârziate, și intermitente 500 și 503 erori API în întreaga regiune. Inginerii Google au început o analiză completă a cauzelor profunde (RCA) și vor furniza informații suplimentare după ce sunt disponibile. ## Remediation Inginerii Google au fost alertați cu privire la perturbarea prin sisteme automatizate de monitorizare și sonde la ora 23:08 US/Pacific la 19 octombrie (20 octombrie 07:08 BST), care au detectat rate ridicate de eroare API, termene de depunere a unui loc de muncă și pierderea accesibilității infrastructurii în Europa-Vest2-b. Echipele de ingineri s-au mobilizat imediat pentru a izola infrastructura afectată și a începe recuperarea: * ** Izolarea traficului:** Inginerii Google au izolat zona de disponibilitate offline (europe-west2-b) prin ajustarea rutei serviciilor regionale în afara infrastructurii afectate, prevenind cererile clientilor cross-zone de la sincronizarea cu obiectivele offline. * ** Reprioritizarea sarcinilor și protecția resurselor:** Inginerii au ajustat alocările programatorilor și limitele de capacitate în cadrul infrastructurii neimpactate pentru a prioritiza rezervările active ale clienților, pentru a reduce disputa de resurse privind sloturile de execuție și pentru a scuti întârzierile în coadă pentru volumul de muncă regional. * ** Restaurarea grilei de putere:** Inginerii instalaţiei de la faţa locului au efectuat o restaurare graţioasă a unei alimentaţii de utilităţi stabile odată ce alimentarea cu utilităţi a revenit, într-o oră. Ca urmare, ei s-au concentrat și au finalizat o resetare și au testat controlerele de automatizare a generatorului de rezervă de urgență pentru a restabili puterea instalației. * ** Reactivarea infrastructurii agresive:** Inginerii Google au repornit sistematic nucleul infrastructurii și serviciilor Google Cloud. * ** Readmission Controlled Traffic:** Odată ce sănătatea sistemului și integritatea de stocare au fost verificate, inginerii au executat treptat, re-admiterea controlată a traficului înapoi în zona Europa-Vest2-b, permițând backlog-uri de locuri de muncă acumulate pentru a șterge fără probleme. Până la 05:10 US/Pacific marți, 20 octombrie (13:10 BST), disponibilitatea serviciilor a fost recuperată pentru marea majoritate a volumului de muncă al clienților, iar rezoluția pentru majoritatea clienților din cadrul serviciilor Google Cloud Platform din regiune a fost confirmată. Ca urmare a recuperării unei mici cozi de muncă izolată rămasă, notificarea de închidere pentru incident a fost postată de 07:03 US/Pacific (15:03 BST). ## Descriere de impact Între luni, 19 octombrie 2026, 23:00 US/Pacific (marţi, 20 octombrie 2026, 07:00 BST) şi marţi, 20 octombrie 2026, 05:10 US/Pacific (13:10 BST), clienţii care utilizează servicii Google Cloud Platform în regiunea Europa-Vest2 au suferit întreruperi ale serviciilor în două faze consecutive, pe o durată totală de 6 ore, 10 minute. În faza inițială de la 23:00 la 04:29 US/Pacific (07:00 la 12:29 BST) (durata 5 ore, 29 minute), clienții au experimentat rate de eroare ridicate, API timeouts, și întârzieri de procesare până la majoritatea serviciilor Google Cloud Platform recuperat. Ca urmare a restaurării serviciilor de platformă, unele lucrări de lucru ale clienților care rulează în situații de calcul motor au avut o coadă de recuperare mai lungă. Prin 04:46 US/Pacific (12:46 BST) noua creatie de masini virtuale a fost reluata si pana la 05:10 US/Pacific (13:10 BST) peste 99% din masinile virtuale ale motorului de calcul erau intr-o stare sanatoasa. Orice clienți rămași care se confruntau probleme Virtual Machine au fost direcționate pentru a depune o problemă de suport pentru clienți ca pe procedura normală. În timp ce pană fizică de energie a fost izolată strict de instalațiile de datecentric din Europa-Vest2-b, unii clienți care desfășoară activități de muncă în zone neafectate (europe-west2-a și europe-west2-c) sau de-a lungul arhitecturilor regionale au avut, de asemenea, un impact neașteptat. Cauzele principale au fost 1\) creșterea instantanee a cererii asupra capacității de calcul neimpactate și 2\) dependențe sincrone de validare a planului de control-plane între limitele interzonale. Produse afectate incluse: BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Regional Persistent Disk, și Cloud SQL. Aceste servicii s-au confruntat cu probleme neașteptate de degradare și eșuare determinate de epuizarea bruscă a capacității de calcul din cauza creșterii cererii și a întârzierilor API-plane de control care așteaptă validarea din zona offline. Încărcăturile și resursele găzduite în întregime în Europa-Vest2-b au devenit inaccesibile. Serviciile de stocare a datelor cu capacitate de eșuare, cum ar fi Cloud SQL, AliadDB, Memorystore for Redis și Cloud Bigtable au eșuat în zonele neafectate din apropiere în timpul întreruperii Europa-Vest2-b. Serviciile multizonale și regionale care se întindeau în întreaga regiune Europa-Vest2 au înregistrat erori de latență, de API tranzitorii (cum ar fi erorile HTTP 500 și 503) și de admisie a sarcinilor, care au stat la baza unui blocaj de trafic concentrat asupra resurselor regionale neafectate și a unor apeluri la zone încrucișate la componente offline temporizate. Operațiunile de scriere a depozitelor din regiune au cunoscut o rată de eroare tranzitorie în timpul perioadei inițiale de eșec, iar cozile regionale de admisie a interogărilor au atins un vârf temporar înainte de a se subsidia rapid ca capacitate reechilibrată. Următoarele servicii Google Cloud Platform au avut impact: * ALYDB for PostgreSQL * Apigee * BigQuery Data Transfer Service * Cloud Data Fusion * Cloud Filestore * Cloud Firestore * Cloud Load Balance * Cloud Memorystore * Cloud NAT * Cloud Run * Cloud Spanner * Statii de lucru Cloud * Datastream * Dialogflow CX * Motor Google App * Google BigQuery * Google Cloud Bigtable * Fluxul de date Google Cloud * Google Cloud Dataproc * Google Cloud NetApp Volumes * Google Cloud Pub/Sub * Google Cloud SQL * Google Cloud Storage (GCS) * Motor de calcul Google (GCE) * Motor Google Kubernetes (GKE) * Google SecOps (Security Information and Event Management \[SIEM\] and Security Orchestration, Automation, and Response \[SOAR\]) * Looker (Google Cloud core) * Looker Studio * Managementul fluxului de aer (Google Cloud Compuser) * Managed Service for Apache Kafka * Memorystore for Memcached * Memorystore for Redis * Memorystore for Redis Cluster * Memorystore for Valkey * Network Connectivity Center * Disc persistent * Private Service Connect * Discurs-la-Text * 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 ----------
Traducere automată din actualizarea oficială a incidentului.