Wiele usług napotkało problemy w regionie Europy Zachodniej2.
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * Mamy do czynienia z problemem wielu usług w Europie-west2 począwszy od poniedziałku 2026-10-19 23: 08 PDT. Nasz zespół inżynieryjny nadal bada sprawę. Dostarczymy aktualizację do wtorku, 2026-10-20 02: 30 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Wiele usług Google Cloud doświadcza zwiększonych błędów i przerywanych awarii sieci w regionie Europy Zachodniej2. * * Workaround * * Na razie żadnych
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * Mamy do czynienia z problemem wielu usług w Europie-west2 począwszy od poniedziałku 2026-10-19 23: 08 PDT. Nasz zespół inżynieryjny nadal bada sprawę. Dostarczymy aktualizację do wtorku, 2026-10-20 04: 00 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Wiele usług Google Cloud występują wysokie błędy i przerywane awarie sieci w regionie Europy Zachodniej2. Notatka: Looker Studio nie ma wpływu na ten przestój. * * Workaround * * Jeżeli jest to wykonalne, wpływający klient może próbować przenieść swoje obciążenie pracą do innego dostępnego miejsca (strefy lub regionu).
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * Mamy do czynienia z problemem wielu usług w Europie-west2 począwszy od poniedziałku 2026-10-19 23: 08 PDT. Nasz zespół inżynieryjny nadal bada sprawę. Dostarczymy aktualizację do wtorku, 2026-10-20 05: 00 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Wiele usług Google Cloud występują wysokie błędy i przerywane awarie sieci w regionie Europy Zachodniej2. Notatka: Looker Studio nie ma wpływu na ten przestój. * * Workaround * * Jeżeli jest to wykonalne, wpływający klient może próbować przenieść swoje obciążenie pracą do innego dostępnego miejsca (strefy lub regionu).
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * Mamy do czynienia z problemem wielu usług w Europie-west2 począwszy od poniedziałku 2026-10-19 23: 08 PDT. Ze względu na awarię zasilania doszliśmy do przestoju w strefie eurowest2b. Wydarzenie z zasilaniem jest ograniczone. Częściowe ograniczenie do usług infrastrukturalnych będzie obserwowane w ciągu najbliższych 30 minut, a pozostałe usługi zostaną tam ograniczone. Dostarczymy aktualizację do wtorku, 2026-10-20 05: 00 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Usługi Google Cloud są niedostępne w strefie europe- west2- b; niektóre usługi w regionie europe- west2 mogą wystąpić wysokie błędy i przerywane problemy sieciowe. * * Workaround * * Jeżeli jest to wykonalne, wpływający klient może próbować przenieść swoje obciążenie pracą do innego dostępnego miejsca (strefy lub regionu).
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * Mamy do czynienia z problemem wielu usług w Europie-west2 począwszy od poniedziałku 2026-10-19 23: 08 PDT. Event energetyczny spowodował awarię w strefie europe- west2- b. Wydarzenie z zasilaniem jest ograniczone. Obserwujemy odzyskiwanie usług i priorytetowo traktujemy odzyskiwanie istniejących obciążeń. Klienci mogą nie być w stanie jeszcze stworzyć nowych obciążeń roboczych. Pełne odzyskiwanie istniejących obciążeń roboczych powinno być zakończone, wstępnie do wtorku 2026- 10- 20 06: 00. Dostarczymy aktualizację do wtorku, 2026-10-20 06: 00 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Usługi Google Cloud są niedostępne w strefie europe- west2- b; niektóre usługi w regionie europe- west2 mogą wystąpić wysokie błędy i przerywane problemy sieciowe. * * Workaround * * Jeżeli jest to wykonalne, wpływający klient może próbować przenieść swoje obciążenie pracą do innego dostępnego miejsca (strefy lub regionu).
- resolved
/ Podsumowanie Wiele usług napotyka problemy w regionie Europy Zachodniej2. * * Opis * * We wtorek 2026- 10- 20 05: 10 PDT widzimy odzyskiwanie usług dla większości zadań w Europie-west2. Dostarczymy aktualizację do wtorku, 2026-10-20 07: 00 PDT z aktualnymi szczegółami. Przepraszamy wszystkich, którzy zostali dotknięci zakłóceniem. * * Objawy * * Usługi Google Cloud są niedostępne w strefie europe- west2- b; niektóre usługi w regionie europe- west2 mogą wystąpić wysokie błędy i przerywane problemy sieciowe. * * Workaround * * Jeżeli jest to wykonalne, wpływający klient może próbować przenieść swoje obciążenie pracą do innego dostępnego miejsca (strefy lub regionu).
- resolved
/ Podsumowanie Wiele usług napotkało problemy w regionie Europy Zachodniej2. * * Opis * * Problem wpływających produktów GCP został złagodzony przez większość klientów i uważa się, że wpływa na obecnie bardzo niewielką liczbę klientów i nasz zespół inżynieryjny pracuje nad tym. Jeśli masz pytania lub mają wpływ, proszę otworzyć sprawę z Zespołem Wsparcia i będziemy pracować z tobą do czasu rozwiązania tego problemu. Nie zostaną tu przedstawione żadne dalsze aktualizacje. Opublikujemy analizę tego incydentu po zakończeniu naszego wewnętrznego śledztwa. Dziękujemy za cierpliwość, kiedy pracujemy nad rozwiązaniem problemu. * * Objawy * * Usługi Google Cloud były niedostępne w strefie europe- west2- b; niektóre usługi w regionie europe- west2 mogły wystąpić wysokie błędy i problemy z siecią przerywaną. * * Workaround * * Brak, ponieważ problem został złagodzony.
- resolved
Wstępne sprawozdanie z incydentu Zdajemy sobie sprawę, że usługi Google Cloud są krytyczne dla Twojej organizacji i szczerze przepraszamy za zakłócenie tego incydentu, który mógł spowodować dla Twojej firmy. Pracujemy nad zajęciem się główną przyczyną i zapobieżeniem temu w przyszłości. Informacje te opierają się na naszej najlepszej wiedzy w momencie delegowania i mogą ulec zmianie w miarę trwania naszego dochodzenia. Ostateczny raport z działań zapobiegawczych zostanie opublikowany po zakończeniu śledztwa. W przypadku wystąpienia oddziaływania poza tym, co jest wymienione poniżej, należy skontaktować się z Google Cloud Support przy użyciu [* * https\: / / cloudd.google.com / support * *] (https: / / cloudd.google.com / support). Data / Czas wydania Początek incydentu: 19 paź 2026 23: 00 US / Pacific / 20 paź 2026 07: 00 BST Koniec incydentu: 20 paź 2026 05: 10 US / Pacific / 20 paź 2026 13: 10 BST Czas trwania: 6 godzin, 10 minut Podsumowanie W poniedziałek, 19 października 2026 r. (wtorek, 20 października BST), wiele usług platformy Google Cloud Platform w regionie Europy Zachodniej2 doświadczyło zakłóceń w obsłudze, zwiększonego poziomu błędów, czasu programowania aplikacji (API) i opóźnienia przetwarzania przez okres 6 godzin i 10 minut. Zakłócenie to zostało wywołane przez awarię zasilania elektrycznego w obiekcie danych hosting strefy dostępności europe- west2-b, który tymczasowo wziął fizyczne serwery hosta, sprzęt routingu sieci i systemy pamięci masowej offline. Spowodowało to następnie wtórne niepowodzenie i opóźnienie w kolejce w ramach niewpływającej infrastruktury regionalnej. # Wstępna przyczyna korzenia Incydent został wywołany, gdy doszło do zakłócenia sieci energetycznej w obiekcie danych hosting strefy dostępności europe- west2- b. Aby utrzymać ciągłą moc podczas zakłóceń, automatyczne przeniesienie do rezerwowych systemów zasilania obiektu zostało natychmiast uruchomione. Obciążenie obiektu zostało przeniesione do banków baterii nieprzerwanego zasilania (UPS) podczas uruchamiania sekwencji awaryjnych generatorów oleju napędowego na miejscu. Programowalny system automatyki sterownika (PLC) (zarówno podstawowe, jak i zapasowe sterowniki PLC) nie zainicjował logicznych operacji automatycznego uruchamiania / transferu generatorów, co uniemożliwiło generatorom kopii zapasowych przyjęcie obciążenia. Po wyczerpaniu rezerw baterii UPS, fizyczne serwery hostingowe, tkanina przełączania sieci i lokalne tablice pamięci dedykowane europe- west2- b utraciły moc i offline. Sekwencja zdarzeń prowadzących do wpływu na klienta była następująca: * O 22: 53 US / Pacific (20 Oct, 06: 53 BST), awaria zasilania elektrycznego wystąpiła w obiekcie datacenter hosting strefy dostępności europe- west2-b, i PLC (Programmable Logic Controller) niedrożność instalacji generatory awaryjne od przyjęcia obciążenia elektrycznego. Obciążenie obiektu było nadal wspierane przez banki baterii UPS aż do wyczerpania baterii, począwszy od 23: 00 US / Pacific (20 października, 07: 00 BST). * Kiedy fizyczne serwery hosta, lokalna infrastruktura pamięci masowej i sprzęt do agregacji sieci w europe- west2- b stracił moc, spowodowało instancje, repliki bazy danych i węzły pracy w tej strefie, aby natychmiast nieosiągalne. * Regionalne mechanizmy traffic- routing i aplikacje klientów zainicjowały automatyczną defaworyzację w kierunku dostępnej infrastruktury w sąsiednich strefach dostępności w regionie. * Cross- zone zdalne rozmowy procedury z regionalnych samolotów kontroli usług skierowane do metadanych i elementów katalogowych w strefie offline napotkane timeout, powodując początkowe stalls składania zadań i skoki opóźnienia API. * Nagłe napływy przekierowanych egzekucji zapytań, awarii bazy danych wysokiej dostępności, i obliczyć obciążenia robocze nasycone dostępne sloty obliczeniowe i zdolności przetwarzania w innych strefach dostępności, tworząc podwyższone kolejki wstępu, opóźnione niepowodzenia bazy danych, i przerywane 500 i 503 błędów API w całym regionie. Inżynierowie Google rozpoczęli pełną analizę przyczyn (RCA) i dostarczą dodatkowych informacji po ich udostępnieniu. # # Regeneracja Inżynierowie Google zostali powiadomieni o zakłóceniach poprzez zautomatyzowane systemy monitorowania i sondy o godzinie 23: 08 US / Pacific 19 października (20 października, 07: 08 BST), które wykryły podwyższony wskaźnik błędów API, timeout składania ofert pracy i utratę zdolności infrastruktury w Europie-West2-b. Zespoły inżynieryjne natychmiast zmobilizowały się, aby odizolować dotkniętą infrastrukturę i rozpocząć odzyskiwanie: * * * Izolacja drogowa: * * Inżynierowie Google wyodrębnili strefę dostępności offline (europe- west2- b) poprzez dostosowanie regionalnych tras usług z dala od dotkniętej infrastruktury, zapobiegając tym samym próbom klientów w strefie przekrojowej przed odłączeniem się od punktów końcowych offline. * * * Workload Reprioritization and Resource Safeguards: * * Inżynierowie dostosowali przydziały rozkładowe i limity zdolności przepustowej w ramach niewpływającej infrastruktury, aby priorytetowo traktować aktywne rezerwacje klientów, zmniejszyć kontencję zasobów na sloty do wykonania i zwolnić zaległości kolejki dla regionalnych zadań. * * * Power Grid Restoration: * * Inżynierowie obiektów na miejscu przeprowadzili pełne gracji odtworzenie stabilnego zasilacza po powrocie zasilania, w ciągu 1 godziny. Następnie skoncentrowali się i zakończyli resetowanie i przetestowali awaryjne kontrolery automatyki generatora w celu przywrócenia zasilania obiektu. * * * Reaktywacja infrastruktury progresyjnej: * * Inżynierowie Google systematycznie restartowali podstawową infrastrukturę i usługi Google Cloud. * * * Controlled Traffic Reading: * * Po zweryfikowaniu integralności systemu w zakresie zdrowia i magazynowania inżynierowie przeprowadzili stopniowe, kontrolowane wjazd z powrotem do strefy europe- west2- b, co pozwoliło na płynne usunięcie nagromadzonych zaległości w pracy. Do 05: 10 US / Pacific we wtorek, 20 października (13: 10 BST), dostępność usług została odzyskana dla większości zadań klientów, a rozdzielczość dla większości klientów w Google Cloud Platform usług w regionie została potwierdzona. Po odzyskaniu małego ogona pozostałych odizolowanych ładunków roboczych, powiadomienie o zamknięciu zdarzenia zostało opublikowane przez 07: 03 US / Pacific (15: 03 BST). # # Opis uderzenia Od poniedziałku, 19 października 2026 r., 23: 00 US / Pacific (wtorek, 20 października 2026 r., 07: 00 BST) do wtorku, 20 października 2026 r., 05: 10 US / Pacific (13: 10 BST), klienci korzystający z usług Google Cloud Platform w regionie Europy Zachodniej2 doświadczyli zakłóceń w obsłudze w dwóch kolejnych fazach, trwających łącznie 6 godzin, 10 minut. W początkowej fazie od 23: 00 do 04: 29 US / Pacific (07: 00 do 12: 29 BST) (czas trwania 5 godzin, 29 minut), klienci doświadczyli podwyższonych wskaźników błędów, API timeout i opóźnienia przetwarzania do większości usług Google Cloud Platform odzyskać. Po renowacji serwisu platformy, niektóre ładunki pracy klienta uruchomione na instancjach Compute Engine doświadczenie dłuższy ogon odzyskiwania. Do 04: 46 US / Pacific (12: 46 BST) wznowiono tworzenie nowej maszyny wirtualnej, a do 05: 10 US / Pacific (13: 10 BST) ponad 99% komputerowych maszyn wirtualnych było w stanie zdrowia. Pozostali klienci, którzy doświadczali problemów z maszyną wirtualną, zostali skierowani do zgłaszania problemu obsługi klienta zgodnie z normalną procedurą. Podczas gdy fizyczny brak zasilania został odizolowany ściśle do obiektów datacenter w Europie-West2-b, niektórzy klienci prowadzący ładunki robocze w strefach bez wpływu (europe- west2-a i europe- west2-c) lub w obrębie architektury regionalnej również doświadczyli nieoczekiwanego wpływu. Głównymi przyczynami były 1\) chwilowe wzrosty popytu na niewpływającej pojemności obliczeniowej i 2\) zależne od kontroli synchronicznej od granic strefy. Dopasowane produkty to: BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Regionalny Dysk Persistent i Cloud SQL. Usługi te charakteryzowały się nieoczekiwaną degradacją i problemami z przezwyciężaniem awarii, spowodowanymi nagłym obliczeniem wyczerpania przepustowości z rosnącego popytu oraz czasownikami API w płaszczyźnie kontrolnej czekającymi na zatwierdzenie ze strefy offline. Ładunki robocze i zasoby hostowane w całości w ramach europe- west2- b stały się nieosiągalne. Usługi przechowywania danych z możliwością przełączania niesprawności, takie jak Cloud SQL, AlloyDB, Memorystore for Redis i Cloud Bigtable, nie powiodły się w pobliskich strefach bez wpływu podczas przestoju europe- west2- b. Usługi wielostrefowe i regionalne, które przebiegały przez obszar Europy Zachodniej2, charakteryzowały się wysokim opóźnieniem, przejściowymi błędami API (takimi jak błędy HTTP 500 i 503) oraz kolejką wstępu do zadań jako ruch awaryjny skoncentrowany na niewpływających zasobach regionalnych i połączeniach międzystrefowych do wyłączonych komponentów. Operacje zapisu zapisu w regionie doświadczyły przejściowego poziomu błędu w początkowym okresie niepowodzenia, a regionalne kolejki przyjmowania zapytań tymczasowo osiągnęły najwyższy poziom, zanim szybko ustąpiły jako ponowne zrównoważenie zdolności. Następujące usługi Google Cloud Platform miały wpływ: * AlloyDB dla PostgreSQL * Apigee * BigQuery Transfer danych Service * Fuzja danych w chmurze * Cloud Filestore * Chmura ognia * Zbilansowanie obciążenia w chmurze * Cloud Memorystore * Cloud NAT * Cloud Run * Cloud Spanner * Cloud Workstations * Datastream * Dialogflow CX * Google App Engine * Google BigQuery * Google Cloud Większe * 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) * Secops Google (Zarządzanie informacjami i zdarzeniami w zakresie bezpieczeństwa\ [SIEM\] i Orchestracja bezpieczeństwa, Automatyzacja i Reakcja\ [SOAR\]) * Looker (rdzeń Google Cloud) * Looker Studio * Zarządzanie przepływem powietrza (Google Cloud Composer) * Zarządzane usługi dla Apache Kafka * Pamiętnik dla Memcached * Memorystore dla Redis * Memorystore for Redis Cluster * Pamiętnik dla Valkey * Centrum połączeń sieciowych * Trwały dysk * Prywatna usługa Connect * Przemówienie do tekstu * Wirtualna prywatna chmura (VPC) * Silnik 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 ----------
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.