Pricing
Status historyRSS updatesStatus API

Powered by Uptimus

    Google Cloud driftsforstyrrelser

    9 Google Cloud incidents · juli 2025 — official updates, affected components, duration and resolution details.

    Tilbage til aktuel status

    Flere tjenester oplevede problemer i Europa-Vest2-regionen.

    Startede 20. oktober 2026 kl. 06.00 UTC · 6h 8m

    OutageStørre hændelse
    1. 20. oktober 2026 kl. 08.35 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi oplever et problem med flere tjenester i Europa-west2 begynder mandag, 2026-10- 19 23: 08 PDT. Vores ingeniørhold fortsætter med at undersøge spørgsmålet. Vi vil levere en opdatering inden tirsdag, 2026-10- 20 02: 30 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Flere Google Cloud-tjenester oplever forhøjede fejl og intermitterende netværksfejl i Europa-west2-regionen. * * Arbejde omkring * * Ingen indtil videre

    2. 20. oktober 2026 kl. 09.24 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi oplever et problem med flere tjenester i Europa-west2 begynder mandag, 2026-10- 19 23: 08 PDT. Vores ingeniørhold fortsætter med at undersøge spørgsmålet. Vi vil levere en opdatering inden tirsdag, 2026- 10- 20 04: 00 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Flere Google Cloud-tjenester oplever forhøjede fejl og intermitterende netværksfejl i Europa-Vest2-regionen. Bemærk: Looker Studio er ikke påvirket af denne afbrydelse. * * Arbejde omkring * * Hvis det er muligt, kan den ramte kunde forsøge at migrere deres arbejdsbyrde til et andet tilgængeligt sted (zone eller region).

    3. 20. oktober 2026 kl. 11.00 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi oplever et problem med flere tjenester i Europa-west2 begynder mandag, 2026-10- 19 23: 08 PDT. Vores ingeniørhold fortsætter med at undersøge spørgsmålet. Vi vil levere en opdatering inden tirsdag, 2026-10- 20 05: 00 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Flere Google Cloud-tjenester oplever forhøjede fejl og intermitterende netværksfejl i Europa-Vest2-regionen. Bemærk: Looker Studio er ikke påvirket af denne afbrydelse. * * Arbejde omkring * * Hvis det er muligt, kan den ramte kunde forsøge at migrere deres arbejdsbyrde til et andet tilgængeligt sted (zone eller region).

    4. 20. oktober 2026 kl. 11.12 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi oplever et problem med flere tjenester i Europa-west2 begynder mandag, 2026-10- 19 23: 08 PDT. På grund af en magtbegivenhed havde vi lidt en afbrydelse inden for Europa-vest-2-b zone. Strømmen er afbødet. Delvis afbødning af infrastrukturtjenester vil blive observeret inden for de næste 30 minutter, og de resterende tjenester vil blive afbødet der efter. Vi vil levere en opdatering inden tirsdag, 2026-10- 20 05: 00 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Google Cloud-tjenester er ikke tilgængelige i Europa-west2- b-zone; nogle tjenester i Europa-west2-regionen kan opleve forhøjede fejl og intermitterende netværksproblemer. * * Arbejde omkring * * Hvis det er muligt, kan den ramte kunde forsøge at migrere deres arbejdsbyrde til et andet tilgængeligt sted (zone eller region).

    5. 20. oktober 2026 kl. 11.58 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi oplever et problem med flere tjenester i Europa-west2 begynder mandag, 2026-10- 19 23: 08 PDT. En strømbegivenhed forårsagede en afbrydelse inden for Europa-west2- b zone. Strømmen er afbødet. Vi ser retablering af tjenester og prioriterer retablering af eksisterende arbejdsbyrder. Kunder kan ikke være i stand til endnu at skabe nye arbejdsbelastninger. Fuld nyttiggørelse af eksisterende arbejdsbyrder skal være afsluttet, forsigtigt ved tirsdag, 2026- 10- 20 06: 00. Vi vil levere en opdatering inden tirsdag, 2026-10- 20 06: 00 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Google Cloud-tjenester er ikke tilgængelige i Europa-west2- b-zone; nogle tjenester i Europa-west2-regionen kan opleve forhøjede fejl og intermitterende netværksproblemer. * * Arbejde omkring * * Hvis det er muligt, kan den ramte kunde forsøge at migrere deres arbejdsbyrde til et andet tilgængeligt sted (zone eller region).

    6. 20. oktober 2026 kl. 12.44 UTCresolved

      * * Oversigt * * Flere tjenester oplever problemer i Europa-Vest2-regionen. * * Beskrivelse * * Vi er vidne til inddrivelse af tjenester for de fleste arbejdsbyrder i Europa-west2 fra tirsdag, 2026-10- 20 05: 10 PDT. Vi vil levere en opdatering inden tirsdag, 2026-10- 20 07: 00 PDT med aktuelle oplysninger. Vi undskylder over for alle, der er berørt af afbrydelsen. * * symptomer * * Google Cloud-tjenester er ikke tilgængelige i Europa-west2- b-zone; nogle tjenester i Europa-west2-regionen kan opleve forhøjede fejl og intermitterende netværksproblemer. * * Arbejde omkring * * Hvis det er muligt, kan den ramte kunde forsøge at migrere deres arbejdsbyrde til et andet tilgængeligt sted (zone eller region).

    7. 20. oktober 2026 kl. 14.03 UTCresolved

      * * Oversigt * * Flere tjenester oplevede problemer i Europa-Vest2-regionen. * * Beskrivelse * * Problemet med påvirkede GCP produkter er blevet reduceret for de fleste af kunderne, og det menes at påvirke i øjeblikket et meget lille antal kunder og vores Engineering Team arbejder på det. Hvis du har spørgsmål eller er påvirket, skal du åbne en sag med Support Team, og vi vil arbejde med dig, indtil dette problem er løst. Ingen yderligere opdateringer vil blive givet her. Vi vil offentliggøre en analyse af denne hændelse, når vi har afsluttet vores interne undersøgelse. Vi takker dig for din tålmodighed, mens vi arbejder på at løse problemet. * * symptomer * * Google Cloud-tjenester var ikke tilgængelige i Europa-west2- b-zone; nogle tjenester i Europa-west2-regionen kan opleve forhøjede fejl og intermitterende netværksproblemer. * * Arbejde omkring * * Ingen som problemet er blevet mildnet.

    8. 22. oktober 2026 kl. 08.42 UTCresolved

      # # Foreløbig hændelsesrapport Vi anerkender, at Google Cloud-tjenester er afgørende for din organisation, og vi oprigtigt undskylde for den afbrydelse, denne hændelse kan have forårsaget for din virksomhed. Vi arbejder på at tage fat på den grundlæggende årsag og forhindre, at dette sker i fremtiden. Bemærk venligst, at disse oplysninger er baseret på vores bedste viden på udstationeringstidspunktet og kan ændres, efterhånden som vores undersøgelse fortsætter. En endelig hændelsesrapport med forebyggende handlinger vil blive offentliggjort, når vores undersøgelse er færdig. Hvis du har oplevet effekt uden for det, der er anført nedenfor, bedes du kontakte Google Cloud Support ved hjælp af [* * https\: / / cloud.google.com / support * *] (https: / / cloud.google.com / support). # # Tidspunkt for udstedelsen Hændelse Start: 19 okt 2026 23: 00 US / Pacific / 20 okt 2026 07: 00 BST Hændelsesslutning: 20 okt 2026 05: 10 US / Pacific / 20 okt 2026 13: 10 BST Varighed: 6 timer, 10 minutter # # Summary Mandag, 19 oktober 2026 (tirsdag, 20 oktober BST), flere Google Cloud Platform-tjenester i Europa-west2 regionen oplevede service forstyrrelser, forhøjede fejlrater, Application Programming Interface (API) timeouts, og behandling latency i en periode på 6 timer og 10 minutter. Afbrydelsen blev udløst af en elektrisk strømafbrydelse på datacenter facilitet hosting tilgængelighed zone europe- west2- b, som midlertidigt tog fysiske værtsservere, netværk routing hardware, og lagringssystemer offline. Dette medførte efterfølgende sekundære forsinkelser og forsinkelser i kø på tværs af upåvirket regional infrastruktur. # Foreløbig rodårsag Hændelsen blev udløst, da et elnet afbrydelse fandt sted på datacenter facilitet hosting tilgængelighed zone europe- west2- b. For at opretholde kontinuerlig strøm under afbrydelsen, automatisk overførsel til anlægget backup elsystemer blev udløst straks. Facilitetsbelastningen blev overført til UPS-batterierne under opstartssekvensen af nøddieselgeneratorer på stedet. Den programmerbare Logic Controller (PLC) automatisering system (både primære og backup PLC) undladt at indlede den logiske automatiske start / overførsel operationer af generatorerne, hvilket forhindrer backup generatorer i at antage belastningen. Når UPS batterireserver blev udtømt, fysiske vært servere, netværk skifte stof, og lokale lagerarrays dedikeret til europe- west2- b mistet strøm og gik offline. Sekvensen af begivenheder, der førte til kundernes indflydelse var som følger: * På 22: 53 US / Pacific (20 okt, 06: 53 BST), en elektrisk effekt afbrydelse opstod på datacenter facilitet hosting tilgængelighed zone europepe- west2- b, og en PLC (programmerbar Logic Controller) start fejl forhindret facilitet nødgeneratorer fra at antage den elektriske belastning. Anlægget belastning fortsatte med at blive støttet af UPS batteribanker indtil batterierne blev udtømt, startende kl 23: 00 US / Pacific (20 okt, 07: 00 BST). * Når den fysiske vært servere, lokale lagerinfrastruktur, og netværk aggregering hardware i europe- west2- b mistede magt, det forårsagede tilfælde, database kopier, og arbejdstager knudepunkter i denne zone til at blive umiddelbart utilgængelig. * Regional trafik-routing mekanismer og klient applikationer indledt automatiseret failover mod tilgængelig infrastruktur i tilstødende tilgængelighed zoner i regionen. * Crosszone fjernopkald fra regionale service kontrol fly rettet til metadata og katalog komponenter i offline zone stødt timeouts, hvilket forårsager indledende job indsendelse boder og API latency spikes. * Den pludselige tilstrømning af omdirigeret forespørgsel henrettelser, high- availability database fejl, og beregne workloads mættet tilgængelige compute slots og behandlingskapacitet i andre tilgængelige zoner, skabe forhøjede entrékøer, forsinket database fejl, og intermitterende 500 og 503 API fejl i hele regionen. Google ingeniører er begyndt en fuld rod årsag analyse (RCA) og vil give yderligere oplysninger, når den er tilgængelig. # Respiration Google ingeniører blev advaret om afbrydelsen via automatiserede overvågningssystemer og sondere på 23: 08 US / Pacific den 19 okt (20 okt, 07: 08 BST), som detekterede forhøjede API fejlforhold, job indsendelse timeouts, og tab af infrastruktur adgang i europe- west2- b. Engineering teams straks mobiliseret til at isolere den berørte infrastruktur og begynde genopretning: * * * Trafikisolering: * * Google ingeniører isoleret offline tilgængelighed zone (europe- west2- b) ved at justere regionale service routing væk fra den berørte infrastruktur, forhindre cross-zone klient anmodninger fra timing ud mod offline endepunkter. * * * Omprioritering af arbejdsbelastning og ressourcebeskyttelse: * * Ingeniører justeret scheduler tildelinger og kapacitetsbegrænsninger på tværs af upåvirket infrastruktur til at prioritere aktive kundereservationer, reducere ressourcekonfliktion på udførelse slots, og lindre kø backlogs for regionale arbejdsbelastninger. * * * Power Grid Restoration: * * Installationsteknikere foretog en yndefuld restaurering af en stabil forsyningsstrøm, når forsyningsforsyningen var tilbage, inden for 1 time. Efter dette, de fokuserede og afsluttede en nulstilling og testede nødgenerator automatisering controllere til at genoprette anlægget strøm. * * * Progressiv infrastruktur Genaktivering: * * Google ingeniører systematisk genstartet kernen Google Cloud infrastruktur og tjenester. * * * Kontrolleret trafiktilbagevenden: * * Når systemet sundhed og opbevaring integritet blev verificeret, ingeniører gennemført gradvis, kontrolleret trafik tilbagevenden tilbage til zone europee- west2- b gør det muligt akkumulerede job backlogs at rydde problemfrit. Ved 05: 10 US / Pacific tirsdag, 20 Oct (13: 10 BST), service tilgængelighed havde genvundet for langt de fleste af kundens arbejdsbyrder, og løsning for de fleste af kunderne på tværs af Google Cloud Platform-tjenester i regionen blev bekræftet. Efter genopretningen af en lille hale af resterende isolerede arbejdsbyrder, blev lukningsanmeldelsen for hændelsen indsendt af 07: 03 US / Pacific (15: 03 BST). # Beskrivelse af virkning Mellem mandag, 19 okt 2026, 23: 00 US / Pacific (tirsdag, 20 okt 2026, 07: 00 BST) og tirsdag, 20 oktober 2026, 05: 10 US / Pacific (13: 10 BST), kunder, der udnytter Google Cloud Platform tjenester i Europa-west2 regionen oplevede service forstyrrelser på tværs af to på hinanden følgende faser, der varede i alt 6 timer, 10 minutter. I den indledende fase fra 23: 00 til 04: 29 US / Pacific (07: 00 til 12: 29 BST) (varighed 5 timer, 29 minutter), kunder oplevede forhøjede fejlrater, API timeouts, og behandling forsinkelser indtil de fleste Google Cloud Platform-tjenester inddrives. Efter platform service restaurering, nogle kunde workloads kører på Compute Engine tilfælde oplevede en længere opsving hale. Ved 04: 46 US / Pacific (12: 46 BST) nye Virtual Machine skabelse genoptaget og ved 05: 10 US / Pacific (13: 10 BST) over 99% af Compute Engine Virtual Machines var i en sund tilstand. Eventuelle resterende kunder, der oplevede Virtual Machine problemer blev rettet til at indsende en kundesupport problem som pr normal procedure. Mens den fysiske strømafbrydelse var isoleret strengt til datacenter faciliteter i Europa-west2- b, nogle kunder kører arbejdsbyrder i upåvirket zoner (europe- west2- a og europe- west2- c) eller på tværs af regionale arkitekturer også oplevet uventede virkninger. De primære årsager var 1\) øjeblikkelige efterspørgsel stigninger på upåvirket computerkapacitet og 2\) synkrone styrings-plan validering afhængigheder på tværs af zonegrænser. Berørte produkter inkluderet: BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Regional Persistent Disk, og Cloud SQL. Disse tjenester oplevede uventet nedbrydning og failover spørgsmål drevet af pludselig beregne kapacitetsudmattelse fra stigende efterspørgsel, og control- plane API timeouts venter på valideringer fra offline zone. Arbejdspladser og ressourcer hostet helt inden for Europa-west2-b blev uopnåelige. Datalagring med fejlovergangskapacitet såsom Cloud SQL, AlloyDB, Memorystore for Redis, og Cloud Bigtable mislykkedes over i nærliggende upåvirkede zoner under Europa-west2- b udfald. Multizonale og regionale tjenester, der spænder over hele Europa-west2 region oplevede forhøjet latency, forbigående API fejl (såsom HTTP 500 og 503 fejl), og task entry queuing som failover trafik koncentreret på upåvirket regionale ressourcer og cross-zone opkald til offline komponenter timet ud. Opbevaring skrive operationer i regionen oplevede en forbigående fejlfrekvens i den oprindelige failover periode, og regionale forespørgsel optagelse køer midlertidigt toppede, før hurtigt aftagende som kapacitet rebalanceret. Følgende Google Cloud Platform-tjenester oplevede indvirkning: * AlloyDB for PostgreSQL * Apigee * BigQuery Data Transfer Service * Cloud Data Fusion * Cloud Filestore * Cloud Firecrease * Cloud Belastning Balancing * Cloud Memorystore * Cloud NAT * Cloud Run * Cloud Spanner * Cloud arbejdsstationer * Datastream * Dialogflow CX * Google App Engine * Google BigQuery * Google Cloud Bigtable * Google Cloud Dataflow * Google Cloud Dataproc * Google Cloud NetApp mængder * 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\] og Security Orchestration, Automation, og Response\ [SOAR\]) * Looker (Google Cloud core) * Looker Studio * Administreret luftstrøm (Google Cloud-komponist) * Managed Service for Apache Kafka * Memorystore for Memcached * Memorystore for Redis * Memorystore for Redis Cluster * Memorystore for Valkey * Netværksforbindelsescenter * Vedvarende disk * Private Service Connect * Speech- to- Text * Virtuel privat Cloud (VPC) * VMWare motor

    9. 27. oktober 2026 kl. 15.13 UTCresolved

      ## 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 ----------

    Automatisk oversat fra den officielle hændelsesopdatering.

    Google Cloud Storage (GCS) kunder oplevede forhøjede latencer og fejlrater, når de udførte upload eller skrive operationer.

    Startede 8. oktober 2026 kl. 11.00 UTC · 1d 5h

    OutageStørre hændelse
    1. 8. oktober 2026 kl. 18.24 UTCresolved

      * * Oversigt * * Google Cloud Storage-kunder oplever forhøjede latencer og fejlrater, når de udfører upload- eller skriveoperationer * * Beskrivelse * * Vi oplever et problem med Google Cloud Storage begynder torsdag, 2026-10- 08 05: 19 PDT. Vores ingeniørhold fortsætter med at undersøge spørgsmålet. Vi vil levere en opdatering inden torsdag, 2026-10- 08 11: 50 PDT med aktuelle oplysninger. * * Kundesymptomer * * * Kunder oplever forhøjede latencer og fejlrater, når de udfører upload eller skrive operationer. * En mindre delmængde af læse operationer kan også opleve øget latency og fejl * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    2. 8. oktober 2026 kl. 18.34 UTCresolved

      * * Oversigt * * Google Cloud Storage-kunder oplever forhøjede latencer og fejlrater, når de udfører upload- eller skriveoperationer * * Beskrivelse * * Vi oplever et problem med Google Cloud Storage begynder torsdag, 2026-10- 08 05: 19 PDT. Indledende lempelser anvendt af vores ingeniørhold fører til observerbare forbedringer i fejlrater i vores interne overvågning. Der arbejdes stadig på at udvikle yderligere lempelser. Vi vil levere en opdatering inden torsdag, 2026-10- 08 12: 00 PDT med aktuelle oplysninger. * * Kundesymptomer * * * Kunder oplever forhøjede latencer og fejlrater, når de udfører upload eller skrive operationer. * En mindre delmængde af læse operationer kan også opleve øget latency og fejl * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    3. 8. oktober 2026 kl. 18.55 UTCresolved

      * * Oversigt * * Google Cloud Storage-kunder oplever forhøjede latencer og fejlrater, når de udfører upload- eller skriveoperationer * * Beskrivelse * * Vi oplever et problem med Google Cloud Storage begynder torsdag, 2026-10- 08 05: 19 PDT. Indledende lempelser anvendt af vores ingeniør team fører til observerbare forbedringer i fejlrater i vores interne overvågning begynder 10: 57 PDT. Der arbejdes stadig på at udvikle yderligere lempelser. Vi vil levere en opdatering inden torsdag, 2026-10- 08 12: 45 PDT med aktuelle oplysninger. * * Kundesymptomer * * * Kunder oplever forhøjede latencer og fejlrater, når de udfører upload eller skrive operationer. * En mindre delmængde af læse operationer kan også opleve øget latency og fejl * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    4. 8. oktober 2026 kl. 19.38 UTCresolved

      * * Oversigt * * Google Cloud Storage-kunder oplever forhøjede latencer og fejlrater, når de udfører upload- eller skriveoperationer * * Beskrivelse * * Vi fortsætter med at afbøde problemet med Google Cloud Storage i vores-centrale 1-region, der begyndte torsdag, 2026-10- 08 05: 19 PDT. De indledende lempelser, som vores ingeniørhold anvender, viser fortsat observerede forbedringer i fejlprocenter. Vores ingeniørhold er aktivt at overvåge miljøet og udrulle yderligere lempelser for fuldt ud at stabilisere tjenesten. Vi vil levere en opdatering inden torsdag, 2026-10- 08 14: 00 PDT med aktuelle oplysninger. * * Kundesymptomer * * * Kunder oplever forhøjede latencer og fejlrater, når de udfører upload eller skrive operationer. * En mindre delmængde af læse operationer kan også opleve øget latency og fejl * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    5. 8. oktober 2026 kl. 20.48 UTCresolved

      * * Oversigt * * Google Cloud Storage-kunder oplever forhøjede latencer og fejlrater, når de udfører upload- eller skriveoperationer * * Beskrivelse * * Vi fortsætter med at afbøde problemet med Google Cloud Storage i vores-centrale 1-region, der begyndte torsdag, 2026-10- 08 05: 19 PDT. De indledende lempelser, som vores ingeniørhold anvender, viser fortsat observerede forbedringer i fejlprocenter. Vores ingeniørhold er aktivt at overvåge miljøet og udrulle yderligere lempelser for fuldt ud at stabilisere tjenesten. Vi vil give en opdatering inden torsdag, 2026-10- 08 16: 00 PDT med aktuelle oplysninger. * * Kundesymptomer * * * Kunder oplever forhøjede latencer og fejlrater, når de udfører upload eller skrive operationer. * En mindre delmængde af læse operationer kan også opleve øget latency og fejl * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    6. 9. oktober 2026 kl. 16.44 UTCresolved

      # # Foreløbig hændelsesrapport Vi undskylder for forstyrrelsen af din forretning. Vi ved, hvor meget du stoler på Google Cloud, og vi beklager virkningen på din produktivitet. Vi arbejder på at tage fat på den grundlæggende årsag og forhindre, at dette sker i fremtiden. Bemærk venligst, at disse oplysninger er baseret på vores bedste viden på udstationeringstidspunktet og kan ændres, efterhånden som vores undersøgelse fortsætter. En endelig hændelsesrapport med forebyggende handlinger vil blive offentliggjort, når vores undersøgelse er færdig. Hvis du har oplevet en effekt uden for det, der er anført nedenfor, bedes du kontakte Google Cloud Support ved hjælp af [https\: / / cloud.google.com / support] (https: / / cloud.google.com / support) # # Tidspunkt for udstedelsen (All time US / Pacific) Hændelse Start: 08 oktober 2026 04: 00 Hændelse Slutning: 08 oktober 2026 16: 30 Varighed: 12 timer, 30 minutter # # Summary På torsdag, 08 oktober 2026, Google Cloud Storage oplevet forhøjede skrive latency og skrive fejlrater i us-central1-regionen i en varighed af 12 timer, 30 minutter. Vi tager omgående skridt til at sikre, at dette ikke sker igen. # Foreløbig rodårsag Google Cloud Storage er afhængig af en meget distribueret backend arkitektur til at behandle og gemme indkommende data. Under hændelsesvinduet oplevede specifikke lagerryglæn-knuder i us-Central1-regionen et lokalt kapacitetsunderskud. Sekvensen af begivenheder, der førte til kundernes indflydelse var som følger: * En trafiksortering optimering med henblik på at løse lokaliserede kapacitetsbegrænsninger forårsaget alvorlig ressourceudnyttelse på specifikke backend lagerknudepunkter i den berørte region. * Denne ressource udmattelse forårsaget backend tjenester håndtering af objektdata indtagelse til at begynde timing ud. * Som et resultat, indgående upload og skrive anmodninger omdirigeret til disse knudepunkter oplevede forhøjet latency og undlod at fuldføre, hvilket resulterer i fejl dukkede op for kunderne. * Samtidig bidrog et separat problem med den underliggende databasetjeneste til yderligere metadatabehandlingsfejl under en del af hændelsesvinduet. Google ingeniører er begyndt en fuld rod årsag analyse (RCA) og vil give yderligere oplysninger, når den er tilgængelig. # Respiration Problemet blev oprindeligt opdaget af Google engineering teams aktivt overvåge systemet telemetri tidligt i hændelsesvinduet. For at afbøde problemet, Google ingeniører udført følgende trin-by-trin strategi: * Ingeniører i første omgang forsøgt dynamisk at tildele ekstra nødkapacitet til den berørte region, men dette blev blokeret af systemiske regionale kapacitetsgrænser. * For at lette det umiddelbare pres, ingeniører selektivt drænet trafik fra de mest overbelastede backend lagerknudepunkter. * En konfigurationsændring blev indsat for at deaktivere trafik sortering optimering, væsentligt reducere ressource overhead på lager motor. * For den samtidige metadata problem, ingeniører rullede tilbage en nylig opdatering til den underliggende metadata database service. Når trafikniveauet stabiliseret og ressourceudnyttelse vendt tilbage til normale basisniveau, de tidligere drænede knudepunkter blev genoprettet til aktiv tjeneste, med succes genoprette normale operationer. # Beskrivelse af virkning Den 08 oktober, 2026, fra 04: 00 til 16: 30 US / Pacific, kunder, der udnytter us- centrale 1 region oplevede forhøjede latency og fejlrater under Cloud Storage upload og skrive operationer. * Kunder primært observeret HTTP 503 UNAVAILAble fejl på WriteObject-operationer og client- side timeouts. * En mindre indvirkning blev også observeret på læse operationer i denne tidsramme. * Cloud Storage operationer i alle andre regioner, samt alle andre Google Cloud-tjenester, forblev upåvirket af denne specifikke begivenhed.

    7. 14. oktober 2026 kl. 07.15 UTCresolved

      # # Incident Report # # Tidspunkt for udstedelsen (All time US / Pacific) * * Tilfælde første forekomst * * Hændelse Start: 08 oktober 2026 04: 00 Hændelse Slutning: 08 oktober 2026 16: 30 Varighed: 12 timer, 30 minutter * * Forekomst * * Gentagelse Start: 09 oktober 2026 04: 05 Gentagelse Slutningen: 09 oktober 2026 09: 46 Varighed: 5 timer, 41 minutter * * Samlet varighed: * * 18 timer, 11 minutter # # Summary På torsdag, 08 oktober 2026, Google Cloud Storage oplevet forhøjede skrive latency og skrive fejlrater, mens du udfører upload eller skrive operationer i us- centrale 1-regionen i en varighed på 12 timer, 30 minutter. Dette blev efterfulgt af en gentagelse fredag, 09 oktober 2026 i us-centrale 1- b zone for en varighed på 5 timer, 41 minutter. Vi tager omgående skridt til at sikre, at dette ikke sker igen. # Root Cause Google Cloud Storage er afhængig af en meget distribueret backend arkitektur til at behandle og gemme indkommende data. Under hændelsesvinduet oplevede specifikke lagerryglæn-knuder i us-Central1-regionen et lokalt kapacitetsunderskud på grund af øget trafik. Sekvensen af begivenheder, der førte til kundernes indflydelse var som følger: * En trafiksortering optimering opdatering af Google Cloud Storage load balancering lag med det formål at løse lokaliserede kapacitetsbegrænsninger forårsagede alvorlig ressourceudnyttelse på specifikke lagerback-end noder i den berørte region ved utilsigtet at omgå standard kapacity- bevidste routing logik, hvilket resulterer i en alvorlig belastning ubalance. * Som følge heraf fik en lille brøkdel af lagringsknuderne i vores centrale region en overvældende andel af indkommende skrive trafik på trods af lav tilgængelig serveringskapacitet. Denne koncentration af trafik førte til ressourceudnyttelse på de berørte backend servere forårsager backend tjenester håndtering af objektdata indtagelse til at begynde timing ud. * Fordi de underliggende tilfælde ikke kunne behandle den høje mængde af anmodninger hurtigt nok, de indgående upload og skrive anmodninger omdirigeret til disse knudepunkter oplevede forhøjet latency og undlod at fuldføre, hvilket resulterer i fejl dukkede op for kunderne. * Samtidig bidrog et separat problem med den underliggende databasetjeneste til yderligere metadatabehandlingsfejl under en del af hændelsesvinduet. * Den gentagelse af problemet den 9. oktober var forårsaget af en ufuldstændig rollback af en upload planner funktion, som brød load balancering mekanisme og overbelastet et et par mindre opbevaring backend noder. # Rengøring og forebyggelse Spørgsmålet blev oprindeligt opdaget den 08 oktober 2026 kl 04: 50 af Google engineering teams aktivt overvåge systemet telemetri tidligt i hændelsesvinduet. For at afbøde problemet, Google ingeniører udført følgende trin-by-trin strategi: * Ingeniører i første omgang forsøgt dynamisk at tildele ekstra nødkapacitet til den berørte region, men dette blev blokeret af systemiske regionale kapacitetsgrænser. * For at lette det umiddelbare tryk, ingeniører selektivt drænet trafik fra de mest overbelastede lagermotor noder. * En konfigurationsændring blev indsat for at deaktivere trafik sortering optimering, væsentligt reducere ressource overhead på lager motor. * For den samtidige metadata problem, ingeniører rullede tilbage en nylig opdatering til den underliggende metadata database service. * Mens disse trin forudsat midlertidig lettelse, en gentagelse af belastningen ubalance krævede yderligere trafik omdirigering og dræning af berørte lagerkomponenter. Hændelsen blev løst permanent, da engineering fuldt tilbage den problematiske belastning balancering konfiguration ændring, genoprette den tidligere kapacitet- bevidste routing adfærd og tillade trafik at distribuere jævnt i regionen. Når trafikniveauet stabiliseret og ressourceudnyttelse vendt tilbage til normale basisniveau, de tidligere drænede knudepunkter blev genoprettet til aktiv tjeneste, med succes genoprette normale operationer. * * Forebyggende aktioner: * * For at sikre, at dette spørgsmål ikke gentager sig, er vi ved at gennemføre følgende forbedringer: - * * Sikker indstilling Ruller: * * Vi opdaterer vores implementeringsprotokoller for at sikre, at load balancering logik ændringer er strengt valideret i alternative, mindre regioner, før de bliver rullet ud til større, højt udnyttede regioner. - * * Intelligent driftskontrol: * * Vi forbedrer lagerlastbalanceringsarkitekturen for at håndhæve kapacitetsbegrænsninger strengt, så det sikres, at trafikfordelingslogikken ikke kan omgå præspilningssikkerhedsforanstaltninger og rutetrafik til klynger, der mangler tilstrækkelige ressourcer. - * * Restkoncentrationsskala Logic: * * Vi gennemfører målrettede forbedringer for at fremskynde intern databevægelse inden for stærkt udnyttede lagerceller, så systemet kan behandle data mere effektivt og håndtere midlertidige læssepigge med større modstandsdygtighed. # Beskrivelse af virkning Den 08 oktober 2026, fra 04: 00 til 16: 30 i us- centrale 1 region og 09 oktober 2026, fra 04: 05 til 09: 46 i us- centrale 1b zone, kunder oplevede forhøjede latency og fejlrater under Cloud Storage uploade og skrive operationer. * * * Upload & skriv fejl: * * Kunder har primært observeret HTTP 503 UNAVAILAble fejl på WriteObject-operationer og client- side timeouts. * * * Forøget skrivelighed: * * Skrivning operationer, der lykkedes oplevede betydeligt højere latencies end normalt. * Cloud Storage operationer i alle andre regioner, samt alle andre Google Cloud-tjenester, forblev upåvirket af denne specifikke begivenhed.

    Automatisk oversat fra den officielle hændelsesopdatering.

    Flere produkter i us- central 1- b oplever nedbrydning af netværksservice.

    Startede 1. september 2026 kl. 14.42 UTC · 4h 10m

    IssuesMindre hændelse
    1. 1. september 2026 kl. 16.03 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplever nedbrydning af netværksservice. * * Beskrivelse * * Vi oplever et netværksproblem fra tirsdag, 2026-09- 01 07: 41 US / Pacific. Det drejer sig om en del af vores centrale område. De resterende zoner i regionen er uberørt. Vores netværk engineering team har sat i lempelser, og vi ser tjenester begynder at komme sig. Vi vil give mere information på tirsdag, 2026-09- 01 09: 30 US / Pacific med aktuelle detaljer. Vi undskylder over for alle, der er berørt af afbrydelsen. * * Kundesymptomer * * Kunder oplever forhøjet pakketab og -fejl. * BigQuery * Cloud Dataflow * Cloud SQL * App Engine * Cloud Run * AlloyDB * Cloud Bigtable * Cloud Spanner * Beregn motor * Cloud VPN * Cloud forbindelse * Cloud NAT * Cloud Filestore * Cloud hybrid forbindelse * Virtuel privat Cloud * Google Kubernetes Engine * Looker (Google Cloud core) * * Arbejde omkring * * * Kunder med service lag reles kan se succesfulde fuldendelser som kun en del af zonen er påvirket. * Kunder, der er hårdt ramt og har tjenester til rådighed i alternative zoner kan svigte til alternative zoner.

    2. 1. september 2026 kl. 16.19 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplever nedbrydning af netværksservice. * * Beskrivelse * * Det drejer sig om en del af vores centrale område. De resterende zoner i regionen er uberørt. Den tilgrundliggende netværksinfrastruktur er blevet fuldt ud genoprettet efter en indsats for at mindske netværkene. Product engineering teams på tværs af Cloud er i øjeblikket validere inddrivelse status for de enkelte tjenester. Vi vil give mere information på tirsdag, 2026-09- 01 10: 00 US / Pacific med aktuelle detaljer. * * Kundesymptomer * * Kunder oplever forhøjet pakketab og -fejl. * BigQuery * Cloud Dataflow * Cloud SQL * App Engine * Cloud Run * AlloyDB * Cloud Bigtable * Cloud Spanner * Beregn motor * Cloud VPN * Cloud forbindelse * Cloud NAT * Cloud Filestore * Cloud hybrid forbindelse * Virtuel privat Cloud * Google Kubernetes Engine * Looker (Google Cloud core) * Apigee * Google SecOps SOAR * * Arbejde omkring * * * Kunder med service lag reles kan se succesfulde fuldendelser som kun en del af zonen er påvirket. * Kunder, der er hårdt ramt og har tjenester til rådighed i alternative zoner kan svigte til alternative zoner.

    3. 1. september 2026 kl. 17.09 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplever nedbrydning af netværksservice. * * Beskrivelse * * Det drejer sig om en del af vores centrale område. De resterende zoner i regionen er uberørt. De fleste af produkterne er kommet sig, og ingeniørholdet validerer stadig nogle få resterende produkteffekter. Vi vil give mere information på tirsdag, 2026-09- 01 11: 00 US / Pacific med aktuelle oplysninger. * * Kundesymptomer * * Kunder oplever forhøjet pakketab og -fejl. * Cloud Run * App Engine Følgende produkter er genvundet * BigQuery * Cloud Dataflow * Cloud Bigtable * Beregn motor * Cloud hybrid forbindelse * Cloud Filestore * Virtuel privat Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud forbindelse * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firecrease * * Arbejde omkring * * * Kunder med service lag reles kan se succesfulde fuldendelser som kun en del af zonen er påvirket. * Kunder, der er hårdt ramt og har tjenester til rådighed i alternative zoner kan svigte til alternative zoner.

    4. 1. september 2026 kl. 18.01 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplever nedbrydning af netværksservice. * * Beskrivelse * * Det drejer sig om en del af vores centrale område. De resterende zoner i regionen er uberørt. De fleste af produkterne er kommet sig, og ingeniørholdet validerer stadig nogle få resterende produkteffekter. Rutinemæssig netværksvedligeholdelse udløste problemer i us- central 1- b. Vi har genvundet den netkapacitet, der blev påvirket og genoprettet alle zone- og regionale tjenester. Vedligeholdelse i regionen er blevet standset, mens der gennemføres proaktive revisioner. Vi vil give mere information på tirsdag, 2026-09- 01 12: 30 US / Pacific med aktuelle detaljer. * * Kundesymptomer * * Kunder oplever forhøjet pakketab og -fejl. * Cloud Run * App Engine Følgende produkter er genvundet * BigQuery * Cloud Dataflow * Cloud Bigtable * Beregn motor * Cloud hybrid forbindelse * Cloud Filestore * Virtuel privat Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud forbindelse * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firecrease * * Arbejde omkring * * * Kunder med service lag reles kan se succesfulde fuldendelser som kun en del af zonen er påvirket.

    5. 1. september 2026 kl. 18.36 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplever nedbrydning af netværksservice. * * Beskrivelse * * Det drejer sig om en del af vores centrale område. De resterende zoner i regionen er uberørt. De fleste af produkterne er kommet sig. De påvirkede produkter Cloud Run og App Engine er også at se opsving og fejlene har sænket præ-hændelse niveauer. Teknikken overvåger og validerer. Rutine netværk stof sti vedligeholdelse udløst uventede problemer i to klynger i us- centrale 1-b. Vi har genvundet den netkapacitet, der blev påvirket og genoprettet alle zone- og regionale tjenester. Vedligeholdelse i regionen er blevet standset, mens der gennemføres proaktive revisioner. Vi vil give mere information på tirsdag, 2026-09- 01 12: 30 US / Pacific med aktuelle detaljer. * * Kundesymptomer * * Kunder oplever forhøjet pakketab og -fejl. * Cloud Run * App Engine Følgende produkter er genvundet * BigQuery * Cloud Dataflow * Cloud Bigtable * Beregn motor * Cloud hybrid forbindelse * Cloud Filestore * Virtuel privat Cloud * Cloud Spanner * Google Kubernetes Engine * Cloud SQL * AlloyDBCloud VPN * Apigee * Cloud forbindelse * Cloud NAT * Looker (Google Cloud core) * Google SecOps SOAR * Cloud Firecrease * * Arbejde omkring * * * Kunder med service lag reles kan se succesfulde fuldendelser som kun en del af zonen er påvirket.

    6. 1. september 2026 kl. 19.12 UTCresolved

      * * Oversigt * * Flere produkter i us- central 1- b oplevede nedbrydning af netværksservice. * * Beskrivelse * * Det drejede sig om en del af vores centrale område. De resterende zoner i regionen var uberørte. Alle de ramte produkter er kommet sig. Fra indledende analyse, rutinemæssige netværk stof sti vedligeholdelse udløst uventede problemer i en klynge i us- centrale 1- b. Vi har genvundet den netkapacitet, der blev påvirket og genoprettet alle zone- og regionale tjenester. Vedligeholdelse i regionen er blevet standset, mens der gennemføres proaktive revisioner. Vi takker Dem for Deres tålmodighed, mens vi arbejdede på at løse problemet. * * Kundesymptomer * * Kunder oplevede forhøjet pakketab og -fejl. * * Arbejde omkring * * Spørgsmålet er blevet afhjulpet.

    7. 3. september 2026 kl. 17.47 UTCresolved

      # # Foreløbig hændelsesrapport Vi undskylder for forstyrrelsen af din forretning. Vi ved, hvor meget du stoler på Google Cloud, og vi beklager indvirkningen på dit miljø. Vi arbejder på at tage fat på den grundlæggende årsag og forhindre, at dette sker i fremtiden. Bemærk venligst, at disse oplysninger er baseret på vores bedste viden på udstationeringstidspunktet og kan ændres, efterhånden som vores undersøgelse fortsætter. En endelig hændelsesrapport med forebyggende handlinger vil blive offentliggjort, når vores undersøgelse er færdig. Hvis du har oplevet en effekt uden for det, der er anført nedenfor, bedes du kontakte Google Cloud Support ved hjælp af https: / / cloud.google.com / support # # Tidspunkt for udstedelsen (All time US / Pacific) * * Incident Start * *: 1 September 2026 07: 41 * * Incident End * *: 1 September 2026 11: 52 * * Varighed * *: 4 timer, 11 minutter # # Summary Tirsdag den 1. september 2026 oplevede nogle kunder i us- central 1- b nedbrydning af netværksservice og tilfældighed isolation i en periode på 4 timer og 11 minutter. Til vores kunder, hvis forretninger blev påvirket under denne afbrydelse, undskylder vi oprigtigt. Dette er ikke det niveau af kvalitet og pålidelighed, vi stræber efter at tilbyde dig, og vi tager øjeblikkelige skridt til at forbedre platformens ydeevne og tilgængelighed. # Foreløbig rodårsag Den umiddelbare tekniske udløser for denne begivenhed var utilsigtet fysisk afbrydelse af netværksfiberoptiske kabler under en rutine hardware vedligeholdelse procedure. En ingeniør udførte en planlagt kapacitetsopgradering på datacenter routere, der understøtter en brøkdel af kapaciteten i us- central 1- b zone. Netværkets arkitektur for hvert datacenter er designet med redundans på tværs af flere routing enheder. Systemet er designet til at være modstandsdygtig over for alle enkeltenheder eller fiber- sti fejl, og de fleste dobbelt- eller triple- fejl påvirker ikke kundens trafik. For at sikre dette, er enheder og fiber stier fysisk adskilt i hvert datacenter, med forskellige strømkilder. En procedurefejl betød, at den fysiske vedligeholdelse handling sekventielt unplugged 100% af fiber stier på tværs af alle enheder inden for 13 minutter. Fejlens art kombineret med aktionens hastighed forhindrede advarsler om forkert handling, der nåede frem til ingeniøren før fuldstændig afbrydelse. Dette resulterede i, at computerkapaciteten i det ramte område blev isoleret fra nettet. Kunderne var ude af stand til at nå deres virtuelle maskiner, og disse virtuelle maskiner kunne ikke etablere forbindelser uden for deres zone. # Respiration Spørgsmålet blev opdaget straks af automatiserede netværk tab overvågningssystemer samt proaktive sonder, som hurtigt engageret netværk engineering og hændelsesrespons teams. For at afbøde den umiddelbare kundepåvirkning flyttede ingeniørholdene aktivt trafikken væk fra den ramte infrastruktur og flyttede automatisk kompatibel lasttrafik til sund kapacitet andre steder i regionen. Samtidig identificerede isenkræmmelsesteknikere på stedet de frakoblede optiske links og reseated fibrene fysisk. Når de fysiske forbindelser blev fuldt genoprettet, normaliserede trafikstrømme og trafikken blev omdirigeret tilbage til at returnere kapacitet til tjeneste. # Beskrivelse af virkning Tirsdag den 1. september, fra 07: 41 til 11: 52 US / Pacific, en del af us- centrale 1b zone oplevede alvorlig nedbrydning af netværk og ressource isolation. * * * Flere berørte produkter: * * Netværksafbrydelsen til / fra en del af us- central 1- b påvirkede flere GCP-produkter for nogle kunder i området. * * * Fejlprocent: * * Trafikstrømmen fald satser for ressourcer hostet i det berørte område nåede 100% under toppen af hændelsen, hvilket resulterer i uopnåelige virtuelle maskiner og forhøjet pakketab. * * Berørte tjenester og funktioner * * * * * Google Compute Engine: * * Manglende adgang til virtuelle maskiner eksternt, og manglende evne for VM 'er til at nå fjerntliggende ressourcer. * * * Google Kubernetes Engine: * * Uopnåelige regionale / zonale klynger og knudepunkter inden for den berørte zone, hvilket giver forsinkede klyngegenopretningstider. * * * Cloud Run / Google App Engine: * * Midlertidige latenstifter og ventende kø aborter som backend arbejdsbyrder automatisk evakueres og flyttes til sund kapacitet. En undergruppe af arbejdsbelastninger i det særligt ramte område oplevede nedbrydning indtil 11: 52 US / Pacific. * * * Cloud SQL, AlloyDB for PostgreSQL, Cloud Spaniner, Google Cloud Bigtable, Cloud Filestore: * * Dataadgang og forbindelse afbrudt for tilfælde lokaliseret strengt til den ramte infrastruktur. * * * Virtual Private Cloud (VPC), Cloud NAT, Apigee, Google BigQuery, Google Cloud Dataflow, Looker, Google SecOps SOAR, Hybrid Connectivitet, Cloud-forbindelse: * * Forhøjet netværkspakke tab, tilslutning dråber, og API timeouts i den ramte zone.

    8. 10. september 2026 kl. 21.20 UTCresolved

      # # Incident Report # # Summary Tirsdag den 1. september 2026 oplevede nogle kunder i vores central1 nedbrydning af netværksservice og tilfældighed isolation i en periode på 4 timer og 11 minutter. Til vores kunder, hvis forretninger blev påvirket under denne afbrydelse, undskylder vi oprigtigt. Dette er ikke det niveau af kvalitet og pålidelighed, vi stræber efter at tilbyde dig, og vi tager øjeblikkelige skridt til at forbedre platformens ydeevne og tilgængelighed. # Root Cause Arrangementet blev udløst af utilsigtet fysisk afbrydelse af netværksfiberoptiske kabler under rutinemæssig vedligeholdelse af hardware. En tekniker foretog en planlagt kapacitetsopgradering på datacenter routere, der understøtter en brøkdel af kapaciteten i us- central 1- b zone og en lille brøkdel af kapaciteten i us- central 1- f zone. Under hånd- on vedligeholdelse, optiske fibre forbinder data center routere til netværket stof blev afbrudt og de optiske transceivers blev erstattet med en transceiver, der understøtter højere tæthed forbindelse. Denne transceiver var ikke kompatibel med transceivere stadig på plads i datacentret stof, forårsager et tab af forbindelse for hver fiber. Netværket er designet med overflødige routere i separate datacenter rum inden for samme bygning, så svigt af en router ikke afbryde service. Vedligeholdelse var beregnet til at opgradere en router ad gangen over flere dage, med trafik diversioner på hvert trin og verifikation mellem trin, at netværket er vendt tilbage til en fuldt tilsluttet tilstand. Men en procedurefejl i den manuelt orkestrerede opgraderingsproces forårsagede, at den komplette liste over transceiver udskiftninger på tværs af alle routere blev udstedt til teknikeren uden instruktioner til at sekvensere arbejdet en router ad gangen. Vedligeholdelsesarbejdsgangen omfattede heller ikke de forventede trin til verifikation af mennesker og software til påvisning af utilsigtet afbrydelse. Som et resultat, teknikeren sekventielt unplugged alle fiber stier på tværs af de berørte enheder inden for 13 minutter. Den hastighed og arten af fejlen forhindrede advarsler om forkert handling fra at nå ingeniør før tilslutning blev tabt. Desuden blev en stående procedure til at stoppe, hvis lys detekteres på fiberoptisk kabel efter afbrydelse ikke fulgt. Dette resulterede i, at computerkapaciteten i det ramte område blev isoleret fra nettet. Kunderne var ude af stand til at nå deres virtuelle maskiner, og disse virtuelle maskiner kunne ikke etablere forbindelser uden for deres zone. # Rengøring og forebyggelse Spørgsmålet blev opdaget straks af automatiserede netværk tab overvågningssystemer samt proaktive sonder, som hurtigt engageret netværk engineering og hændelsesrespons teams. For at afbøde den umiddelbare kundepåvirkning flyttede ingeniørhold aktivt trafikken væk fra den ramte infrastruktur. Samtidig identificerede hardwareoperationsteknikerne de frakoblede optiske links og genindsatte de originale optiske transceivere fysisk. Når de fysiske forbindelser blev fuldt genoprettet, normaliserede trafikstrømme og trafikken blev omdirigeret tilbage til at returnere kapacitet til tjeneste. Google er forpligtet til at forhindre en gentagelse af dette spørgsmål i fremtiden og er ved at fuldføre følgende aktioner: * Forstærket træning i us- centrale 1 region og globalt omkring sikker vedligeholdelse teknikker, herunder det obligatoriske krav om at kontrollere, om lys er på hver unplugged fiber. * Afslut migration af netværk opgradering arbejdsgange til en fuldt automatisk sekventeret orkestersystem. De fleste fælles regionale netværk arbejdsgange blev afsluttet i 2025, og zonearbejdsgange er i gang. * Fuldføre indførelsen af arbejde stop alarmering for handlinger, der resulterer i utilsigtet afbrydelse af live fiber kabler i Google datacentre. * Fuldføre indførelsen af det automatiserede system, der vil flytte regional trafik væk fra defekte zoner, reducere tiden fra ca. 19 minutter i dette tilfælde til omkring 5 minutter. # Detaljeret beskrivelse af virkning Tirsdag den 1. september, fra 07: 41 til 11: 52 US / Pacific, en del af us-centrale 1b og us-centrale 1f zoner oplevede alvorlig nedbrydning af netværk og ressource isolation. 1. Flere produkter påvirket: Netværksforstyrrelser til / fra en del af us- centrale 1- b og us- centrale 1- f zoner påvirket alle zonal GCP produkter for nogle kunder i disse zoner. 2. Regional indvirkning: Regionale produkter, der bruger kapacitet i det berørte datacenter blev påvirket, indtil trafik omdirigeringer var fuldt på plads kl 08: 00 US / Pacific. Google Kubernetes Engine og Cloud Run / Google App Engine havde længere virkninger, drøftet nedenfor. 3. Fejlprocent: Trafikstrømmen fald satser for ressourcer hostet i det berørte område nåede 100% under toppen af hændelsen, hvilket resulterer i uopnåelige virtuelle maskiner og forhøjet pakketab. * * Berørte tjenester og funktioner * * * Google Compute Engine: Manglende evne for brugere i den berørte del af us- central 1- b og us- centrale 1- f zoner til at få adgang til virtuelle maskiner eksternt, og manglende evne for VM til at nå fjerntliggende ressourcer. * Cloud SQL, AlloyDB for PostgreSQL, Google Cloud Bigtable, Cloud Filestore: Dataadgang og forbindelse afskåret for tilfælde lokaliseret strengt til den ramte infrastruktur. * Cloud Spanner, Cloud Firecrease: Forhøjet Remote Procedure Call (RPC) fejlrater, skrive timeouts, og latency spikes for nam5 multi- region tilfælde på grund af afskåret tilslutning til komponenter, der kører i den ramte zone. * Virtual Private Cloud (VPC), Cloud NAT, Apigee, Google BigQuery, Google Cloud Dataflow, Looker, Google SecOps SOAR, Hybrid Connectivity, Cloud Interconnect: Forhøjet netværk pakke tab, tilslutning dråber, og API timeouts i den ramte zone. * Google Kubernetes Engine (GKE): Mellem 07: 40 og 09: 15 US / Pacific den 2026- 09- 01, kunder oplevede fejl og timeouts på anmodninger til deres GKE klyngestyringsfly (Kubernetes API-servere) i us- central1. Dette kunne have forårsaget nye eller opdaterede arbejdsbelastninger til at mislykkes planlægning og Kubernetes API-operationer til at mislykkes. * Cloud Run / Google App Engine: Midlertidige latency spikes og venter kø aborts som backend arbejdsbelastning automatisk evakueret og flyttet til sund kapacitet. En undergruppe af arbejdsbelastninger i det særligt ramte område oplevede nedbrydning indtil 11: 52 US / Pacific. * * Kundeeffekt * * Kunder med ressourcer hostet i de specifikke berørte klynger i us- central 1- b og us- central 1- f oplevede et fuldstændigt tab af netværksforbindelse startende på 07: 41 US / Pacific. I løbet af denne periode blev virtuelle maskiner og tilknyttede tjenester utilgængelige fra internettet og fra andre Google Cloud-regioner, og disse interne ressourcer kunne ikke indlede udgående forbindelser. Problemet blev opdaget næsten øjeblikkeligt og ingeniører tog trafik omdirigering foranstaltninger på 07: 45 og 08: 00 US / Pacific at reducere virkningen til regionale produkter. Ved 08: 50 US / Pacific, de fleste fysiske forbindelser blev genoprettet og trafikken begyndte at komme sig, og trafikken omdirigering aktioner blev fjernet på 09: 19 US / Pacific. Fuld genopretning på tværs af næsten alle berørte tjenester og langvarig drift blev bekræftet af 11: 52 US / Pacific. Da isolationen af nettet var strengt begrænset til specifikke klynger inden for us-central 1-b og us-central 1-f, kunne multizonedeployeringer korrekt udnytte redundans på tværs af andre zoner i us-central 1 stort set omgå den fysiske hardware fejl og fortsætte med at betjene trafikken. Kunder med projekter i både us- central 1- b og us- central 1- f ville ikke have set multi-zonal indvirkning - på de fleste af deres zoner ville have kapacitet i det berørte datacenter.

    9. 29. september 2026 kl. 16.09 UTCresolved

      # Addendum to Incident Report Dette tillæg udvider den detaljerede beskrivelse af virkningen fra den foregående meddelelse. Selv om kun to klynger i et datacenter i us-central 1b og us-central 1f erfarne netværk isolation, nogle få regionale produkter med en afhængighed af de berørte datacenter blev også påvirket. Mellem 07: 41 og 11: 52 US / Pacific tirsdag den 1. september 2026 blev følgende produkter påvirket: - * * Compute Engine VMs * *: VMs kører i det berørte datacenter mistede netværksforbindelse til ressourcer placeret uden for deres datacenter. Fra et Compute Engine perspektiv, denne hændelse kun berørt en delmængde af VM i us- centrale 1- b og us- centrale 1- f. - * * Zone og regionale produkter baseret på Compute Engine * * Produkter med afhængigheder på VM 'er i de berørte datacenter oplevede symptomer som tilslutning timeouts eller service manglende tilgængelighed, fordi de underliggende VM' er mistede netværksforbindelse. Eksempler på produkter, der er baseret på Compute Engine VMs omfatter: Apigee, Cloud SQL, AlloyDB for PostgreSQL, Dataflow, Cloud Filestore, og Looker. - * * Google Kubernetes Engine (GKE) * *: GKE-klynger, hvis styreplan havde afhængige af Compute Engine VMs i de berørte klynger oplevede fejl og timeouts, når administratorer eller knudepunkter forsøgte at oprette forbindelse til Kubernetes API-server. Derfor kan deployeringer være blevet forsinket, Kubernetes API operationer kan have slået fejl, og nye knudepunkter kan ikke have registreret med kontrolplanet (forårsager node pool operationelle forsinkelser). - * * Cloud Run og App Engine: * * Arbejdsbelastning i den us- centrale 1-region oplevede forhøjet servering latency, 5xx afbrudt anmodning fejl, og udgående konnektivitet forringelse. For at forhindre alvorlige anmodninger fejl, trafik blev omdirigeret til andre klynger. Diverting anmodninger til andre klynger midlertidigt forårsaget forhøjet latency eller fejl i disse klynger. Når den ramte klynge blev genoprettet, skabte efterspørgslen efter arbejdsbyrde for disse nye backends en "thuding besætning" af samtidige eksempler initialiseringer. Denne pludselige bølge omgik varme caches og overvældede interne fileserings niveauer, udvide symptomer indtil nødkapacitet blev leveret. - * * Andre Google API 'er og tjenester * *, i us- central 1 eller en multi- region, der omfatter us- central 1, blev påvirket, hvis de havde afhængige af softwareopgaver i de berørte klynger og ikke var i stand til at bruge softwareopgaver i en upåvirket klynge. Symptomer omfattede tilslutning timeouts eller service manglende tilgængelighed. Eksempler på andre Google API' er og tjenester er: Google Cloud Bigtable, BigQuery, Google SecOps SOAR, Cloud Spaniner og Cloud Firecrease. For nogle tjenester var symptomerne begrænset til midlertidige latency spikes og service manglende tilgængelighed indtil arbejdsbelastning flyttet til uberørte klynger. - * * Private Service Connect * *: Klienter (i en hvilken som helst region) oplevede problemer med forbindelse, der involverede PSC-endepunkter med afhængighed1, under særlige omstændigheder: - PSC-endepunkter for Google API 'er blev påvirket på samme måde som anført i afsnittet om Google API' er og tjenester. - Producent / forbruger PSC-endpoints blev påvirket, hvis producenten havde belastningsballancere eller backend VM 'er i de berørte klynger af us-central1. - * * Hybrid forbindelse * *: Nogle Cloud Router, Cloud VPN, og Cloud Interconnect VLAN vedhæftede filer i us- central1 blev påvirket under særlige omstændigheder: - Cloud Router BGP software opgaver for nogle Cloud Routers i us- centrale 1 oplevede en Cloud Router vedligeholdelse begivenhed, hvis deres BGP software opgaver kørte i de berørte klynger. - Cloud VPN tunnel software opgaver kører i de berørte klynger mistede netværksforbindelse. Dette forårsagede nogle Cloud VPN tunneller i us- central1 at gå ned indtil en udskiftning tunnel opgave i en anden klynge blev tildelt. - Ressourcer (i enhver region) sende pakker gennem Cloud Interconnect VLAN vedhæftede filer i us- central1 kunne have oplevet intermitterende forbindelsesproblemer i visse situationer, hvor netværksstrømme ikke allerede var programmeret. - * * Load balancere og andre produkter baseret på elektrisk energi * *: Indlæs ballancere og andre produkter, der afhang af forvaltede Envoy opgaver af en proxy- kun subnet i us- central1 oplevede øget latency eller forbindelse problemer, hvis nok Envoy opgaver var i de berørte klynger. Følgende produkter blev påvirket: - Regional ekstern applikationsbelastningsballancer i us-Central1 - Regional intern applikationsbelastningsballancer i us-Central1 - Cross- region intern applikationsbelastningsballancer med proxyer i us-Central1 - Regional ekstern proxy netlastballancer i us-Central1 - Regional intern proxy netlastballancer i us-Central1 - Cross- region intern proxy netlastballancer med proxyer i us-Central1 - Secure Web Proxy i us-Central1

    Automatisk oversat fra den officielle hændelsesopdatering.

    Vi undersøger et problem, hvor kunderne kan opleve timeouts, service nedbrydninger, fejl, og forhøjede ventetider på tværs af flere produkter i us-west1-regionen.

    Startede 20. august 2026 kl. 15.40 UTC · 3h 40m

    OutageStørre hændelse
    1. 20. august 2026 kl. 16.44 UTCresolved

      * * Oversigt * * Vi undersøger et problem, hvor kunderne kan opleve timeouts, service nedbrydninger, fejl, og forhøjede ventetider på tværs af flere produkter i us-west1-regionen. * * Beskrivelse * * Vi oplever et problem med flere produkter, der begynder torsdag, 2026-08- 20 08: 40 PDT. Vores ingeniørhold fortsætter med at undersøge spørgsmålet. Vi vil give en opdatering inden torsdag, 2026-08- 20 10: 30 PDT med detaljer. Vi undskylder over for alle, der er berørt af afbrydelsen. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Ingen på nuværende tidspunkt.

    2. 20. august 2026 kl. 17.13 UTCresolved

      * * Oversigt * * Vi undersøger et problem, hvor kunderne kan opleve timeouts, service nedbrydninger, fejl, og forhøjede ventetider på tværs af flere produkter i us-west1-regionen. * * Beskrivelse * * Mitigation aktioner gennemføres af vores ingeniørhold, opsving tendenser er blevet observeret på tværs af infrastruktur lag. Aktive bestræbelser på at bringe de berørte cloud-tjenester tilbage til fuld drift. Vi vil levere en opdatering på torsdag, 2026-08- 20 10: 45 PDT med detaljer. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Vi anbefaler kunderne at svigte andre regioner, hvor det er muligt.

    3. 20. august 2026 kl. 17.32 UTCresolved

      * * Oversigt * * Vi undersøger et problem, hvor kunderne kan opleve timeouts, service nedbrydninger, fejl, og forhøjede ventetider på tværs af flere produkter i us-west1-regionen. * * Beskrivelse * * Mitigation aktioner gennemføres af vores ingeniørhold, opsving tendenser er blevet observeret på tværs af infrastruktur lag. Aktive bestræbelser på at bringe de berørte cloud-tjenester tilbage til fuld drift. Vi vil levere en opdatering inden torsdag, 2026-08- 20 11: 00 PDT med detaljer. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Vi anbefaler kunderne at svigte andre regioner, hvor det er muligt.

    4. 20. august 2026 kl. 18.03 UTCresolved

      * * Oversigt * * Det problem, der forårsager timeouts, nedbrydninger, fejl, og latesser på tværs af flere use- west1 produkter er blevet afbødet, og vi arbejder på at inddrive alle produkter. * * Beskrivelse * * Mitigation handlinger er blevet afsluttet af vores ingeniørhold, og vi ser inddrivelse fra flere produkter. Vi arbejder fortsat på at genvinde de resterende produkter. Vi vil give en opdatering inden torsdag, 2026-08- 20 11: 45 PDT med detaljer. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Der er ikke brug for noget arbejde lige nu.

    5. 20. august 2026 kl. 18.53 UTCresolved

      * * Oversigt * * Det problem, der forårsager timeouts, nedbrydninger, fejl, og latesser på tværs af flere use- west1 produkter er blevet afbødet, og vi arbejder på at inddrive alle produkter. * * Beskrivelse * * Mitigation handlinger er blevet afsluttet af vores ingeniørhold, og vi ser inddrivelse fra flere produkter. Vi arbejder fortsat på at genvinde de resterende produkter. Vi vil give en opdatering inden torsdag, 2026-08- 20 12: 30 PDT med detaljer. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Der er ikke brug for noget arbejde lige nu.

    6. 20. august 2026 kl. 19.21 UTCresolved

      * * Oversigt * * Det problem, der forårsager timeouts, nedbrydninger, fejl, og latesser på tværs af flere use- west1 produkter er blevet afbødet, og vi arbejder på at inddrive alle produkter. * * Beskrivelse * * Mitigation handlinger er blevet afsluttet af vores ingeniørhold, og vi ser inddrivelse fra flere produkter. Vi arbejder fortsat på at genvinde de resterende produkter. Vi vil give en opdatering inden torsdag, 2026-08- 20 13: 30 PDT med detaljer. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan opleve timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Der er ikke brug for noget arbejde lige nu.

    7. 20. august 2026 kl. 19.37 UTCresolved

      * * Oversigt * * Det problem, der forårsager timeouts, nedbrydninger, fejl, og latesser på tværs af flere use- west1 produkter er blevet mildnet. * * Beskrivelse * * Vi har mindsket problemet påvirker flere produkter i vores os- west1 region fra torsdag, 2026-08- 20 10: 22 PDT. Vores ingeniørhold har genoprettet kapaciteten på en planlagt optisk vedligeholdelse, der forårsagede uventet overbelastning i Delles, Oregon metro / us- west1 region. Vores systemer er stabiliseret, og tjenesterne er genoprettet, når kapaciteten er genoprettet. Vores hold fortsætter med at overvåge for eventuelle resterende effekt. Vi vil offentliggøre en analyse af denne hændelse, når vi har afsluttet vores interne undersøgelse. Vi takker Dem for Deres tålmodighed, mens vi arbejdede på at løse problemet. * * Diagnose / kundesymptomer * * Kunder i us-west1 kan have oplevet timeouts, service nedbrydninger, fejl, og forhøjede latesser på tværs af flere produkter. * * Arbejde omkring * * Dette spørgsmål er nu afbødet.

    8. 25. august 2026 kl. 06.20 UTCresolved

      # Foreløbig hændelsesrapport Vi undskylder for forstyrrelsen af jeres forretninger. I erkendelse af din afhængighed af Google Cloud, udtrykker vi vores oprigtige beklagelse for enhver operationel indvirkning oplevet. Vores ingeniørhold tager aktivt fat på den underliggende årsag til at forhindre fremtidige gentagelser. Bemærk venligst, at oplysningerne heri afspejler vores nuværende forståelse fra udgivelsestidspunktet og fortsat er genstand for revision, efterhånden som undersøgelsen skrider frem. Der vil blive udsendt en omfattende rapport om forebyggende foranstaltninger efter afslutningen af vores undersøgelse. Hvis du har oplevet en effekt uden for det, der er anført nedenfor, bedes du kontakte Google Cloud Support ved hjælp af https: / / cloud.google.com / support. # # Tidspunkt for udstedelsen (All time US / Pacific) * Tilfælde Start: 20 August 2026 08: 00 * Incident End: 20 August 2026 10: 22 * Varighed: 2 timer, 22 minutter # # Summary Torsdag, 20 August 2026, flere Google Cloud-tjenester stødte på forhøjet latency, levering fejl, øgede fejlrater, og service nedbrydninger varer i en periode på 2 timer og 22 minutter. # Foreløbig rodårsag Afbrydelsen opstod under planlagt fiberoptisk vedligeholdelse, som uventet kompromitteret netværkskapacitet mellem datacentre i us-west1-regionen. Automatiske omdirigeringsmekanismer kunne ikke korrekt omfordele trafikken til alternativ kapacitet, hvilket resulterede i netoverbelastning, da mængderne oversteg den tilgængelige båndbredde i det berørte område. Denne underliggende nedbrydning af nettet påvirkede efterfølgende servicekomponenterne på højere niveau gennem anmodning om at blive kvalt, øget latens og cascading-forsøg. Derfor lykkedes det ikke både at udføre operationer med kontrolfly og anmodninger om data-fly på tværs af flere afhængige Google Cloud-tjenester, hvilket frembragte de observerede latency og forhøjede fejlrater. # Respiration Intern overvågning advarede Google ingeniører til hændelsen, bekræfter, at flere tjenester på tværs af os-west1 blev påvirket. For at afbøde den umiddelbare operationelle virkning, ingeniører indledt trafik dræning protokoller, omdirigering service arbejdsbelastning væk fra den nedbrudte netværk infrastruktur. Efter genoprettelsen af intercampus-netværkets kapacitet og løsningen af kerneproblemet genoprettede ingeniører systematisk trafikken til vores vestregion og bekræftede normaliseringen af tjenesten. Langsigtede engineering løsninger er i øjeblikket ved at blive afsluttet og tildeles til at løse den grundlæggende årsag og styrke systemets modstandsdygtighed med hensyn til fiber vedligeholdelse procedurer. # Beskrivelse af virkning Torsdag den 20. august, mellem 08: 00 og 10: 22 US / Pacific, Google Cloud kunder i us-west1-regionen stødte forhøjet latency, levering fejl, og øgede fejlrater. * Proportionate Impact / Fejl satser: Det præcise omfang af virkningen - herunder andelen af berørte projekter og applikationer - og detaljerede fejlmålinger vil blive offentliggjort i den omfattende Root Cause Analysis, da den reducerede kapacitet forårsagede anmodning kvælning, latency spikes, og øget gensøgningsvolumen. * Anvendelsesområde Udelukkelse: Tjenester og arbejdsbyrder, der opererer i andre regioner end us-west1, forblev fuldt operationelle og upåvirkede. * * Berørte tjenester og funktioner * * Følgende tjenester oplevede forhøjede latencer og / eller øgede fejlrater på tværs af deres respektive data- og kontrolplaner: * AlloyDB * Apache Kafka * Apigee Edge Public Cloud * Apigee X * Artefakt register * BigQuery & BigQuery Data Transfer Service * Cloud Build * Cloud Data Fusion * Cloud Dataflow * Cloud Filestore * Cloud Key Management Service (KMS) * Cloud Overvågning * Cloud Run * Cloud SQL * Kontakt Center AI Platform * Dataproc Metastore * Google App Engine * Google Cloud Bigtable * Google Cloud Pub / Sub * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Identitets- og adgangsstyring (IAM) * Administreret luftstrøm (Cloud Komponist) * Managed Service for Apache Spark (Dataproc) Vedvarende disk

    9. 27. august 2026 kl. 21.45 UTCresolved

      # Incident Report # # Summary Torsdag den 20. august 2026, fra 08: 00 til 10: 22 US / Pacific (15: 00 til 17: 22 UTC), flere Google Cloud-tjenester i us-west1-regionen oplevede forhøjet latency, levering fejl, øgede fejlrater, og omfattende service nedbrydninger i en samlet varighed på 2 timer og 22 minutter. Hændelsen påvirkede en bred vifte af centrale tjenester - herunder Vedvarende Disk, Google Kubernetes Engine, Google Compute Engine, Cloud Run, Google Cloud Bigtable, Cloud Storage, og Identitet og Access Management - på tværs af både kontrol fly operationer og data plane anmodninger. Vi undskylder virkelig for den forstyrrelse denne hændelse forårsaget af din virksomhed operationer og kritiske arbejdsbyrder. Vi anerkender den afgørende rolle, som Google Cloud spiller i at støtte din organisation, og vi beklager dybt indvirkningen på dine forretningsaktiviteter og kritiske arbejdsbyrder. Ingeniør- og infrastrukturhold gennemfører aktivt foranstaltninger til at afhjælpe de grundlæggende årsager og styrke netværkets modstandsdygtighed for at forhindre rekreationer i fremtiden. specielt er holdene i færd med at overvåge fremskridt med hensyn til genopretning, forbedre sikkerhedskontrollen med henblik på planlagt optisk vedligeholdelse og optimere de regionale trafikstyringsmekanismer for at sikre mod uventede kapacitetsbegrænsninger. # Root Cause Afbrydelsen opstod under planlagt fiberoptisk vedligeholdelse, som uventet kompromitteret netværkskapacitet mellem datacentre i us-west1-regionen. Automatiske omdirigeringsmekanismer kunne ikke korrekt omfordele trafikken til alternativ kapacitet, hvilket resulterede i netoverbelastning, da mængderne oversteg den tilgængelige båndbredde i det berørte område. Denne underliggende nedbrydning af netværket påvirkede efterfølgende servicekomponenterne på højere niveau gennem alvorligt pakketab, anmodning om at blive kvalt og øget latenstid på tværs af områder, der afhænger af hinanden. Kerneinfrastrukturtjenester, herunder Spanner Paxos konsensus og Unified Metadata Server (UMS), oplevede betydelige latency spikes, som cascaded i timeouts og forhøjede fejlrater for downstream-afhængige produkter såsom Cloud Storage, Cloud IAM, Persistent Disk, og Google Kubernetes Engine. Derfor lykkedes det ikke både at udføre operationer med kontrolfly og anmodninger om data-fly på tværs af flere Google Cloud-tjenester i us-west1 i hele hændelsen. # Rengøring og forebyggelse Interne overvågningssystemer oprindeligt opdaget udbredte service anomalier og advaret Google ingeniører, der straks bekræftet, at flere centrale tjenester, der opererer på tværs af us-west1 region var alvorligt påvirket. Som reaktion på de umiddelbare operationelle risici, engineering teams straks udført nødtrafik dræning protokoller til at omdirigere aktive tjeneste arbejdsbelastninger væk fra den kompromitterede intercampus netværk infrastruktur og minimere yderligere kundeforstyrrelser. Når teams restaureret inter-campus fiber netværk kapacitet, ingeniører systematisk genindført produktion trafik tilbage til us-west1 gennem kontrollerede valideringsfaser, i sidste ende bekræfter fuld service normalisering på tværs af alle ramte platforme. Længere sigt engineering oprensninger og arkitektoniske forbedringer er aktivt ved at blive afsluttet og tildelt til ejer teams. De vigtigste fokusområder omfatter en reform af de planlagte vedligeholdelsesprotokoller, indførelse af strengere sikkerhedskontroller og krav til redundans forud for rutinemæssig vedligeholdelse, og raffinering af automatiserede regionale trafikstyringsmekanismer til automatisk håndtering af pludselig kapacitetsforringelse uden at medføre alvorlige netbelastninger. # Detaljeret beskrivelse af virkning Torsdag den 20. august, mellem 08: 00 og 10: 22 US / Pacific, Google Cloud kunder i us-west1-regionen stødte forhøjet latency, levering fejl, og øgede fejlrater. * * * Påvirknings- / fejlrater: * * Den reducerede kapacitet forårsagede en anmodning om at blive kvalt, latenstid stiger og øget returvolumen. Anvendelsesområde Udelukkelse: * * Tjenester og arbejdsbyrder i andre regioner end us-west1 forblev fuldt operationelle og upåvirkede. * * Berørte tjenester og funktioner * * Følgende tjenester oplevede forhøjede latencer og / eller øgede fejlrater på tværs af deres respektive data- og kontrolplaner: * AlloyDB * Apache Kafka * Apigee Edge Public Cloud * Apigee X * Artefakt register * BigQuery & BigQuery Data Transfer Service * Cloud Build * Cloud Data Fusion * Cloud Dataflow * Cloud Filestore * Cloud Key Management Service (KMS) * Cloud Overvågning * Cloud Run * Cloud SQL * Kontakt Center AI Platform * Dataproc Metastore * Google App Engine * Google Cloud Bigtable * Google Cloud Pub / Sub * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Identitets- og adgangsstyring (IAM) * Administreret luftstrøm (Cloud Komponist) * Managed Service for Apache Spark (Dataproc) * Vedvarende disk Den regionale hændelse i vores-west1 fulgte en struktureret trefaset opsving dikteret af platform afhængighed lag: Mens centrale platform konnektivitet og live request servering blev restaureret af 10: 22 US / Pacific, visse tjenester tog ekstra tid til helt at komme sig på grund af asynchronous backlog behandling og lokaliseret control- plane state forsoning for et meget lille sæt af kunder. For eventueldrevne og rørledningstjenester faldt den indgående fejlfrekvens til 0 med det samme, men nogle operationer oplevede forhøjet latenstid, mens arbejdere behandlet gennem backlogs akkumuleret under udfald, clearing senere for Cloud Pub / Sub, Cloud Build & Deploy, Cloud Dataflow, og Cloud Storage livscyklusletninger. Samtidig, mens primær læse / skrive trafik var sund i hele regionen, specifikke langløbende livscyklusarbejdsgange krævede ekstra tid til at rydde låse og forene distribuerede state maskiner. Compute Engine VM levering i zone us- west1-c og Cloud Filestore kontrol plane instance tildeling låse og ressource validering kontrol tog længere tid at normalisere på tværs af regionale lagringsenheder.

    Automatisk oversat fra den officielle hændelsesopdatering.

    Google Cloud VMware Engine (GCVE), Google Cloud NetApp Volumes, and Bare Metal Solutions (BMS) services are experiencing a service outage in europe-west4-a due to a cooling failure.

    Startede 15. juli 2026 kl. 23.57 UTC · 12h 28m

    OutageStørre hændelse
    1. 16. juli 2026 kl. 03.30 UTCresolved

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

    2. 16. juli 2026 kl. 04.17 UTCresolved

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

    3. 16. juli 2026 kl. 04.41 UTCresolved

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

    4. 16. juli 2026 kl. 06.29 UTCresolved

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

    5. 16. juli 2026 kl. 07.39 UTCresolved

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

    6. 16. juli 2026 kl. 08.32 UTCresolved

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

    7. 16. juli 2026 kl. 09.21 UTCresolved

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

    8. 16. juli 2026 kl. 10.14 UTCresolved

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

    9. 16. juli 2026 kl. 11.39 UTCresolved

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

    10. 16. juli 2026 kl. 12.25 UTCresolved

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

    11. 18. juli 2026 kl. 00.22 UTCresolved

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

    12. 25. juli 2026 kl. 13.16 UTCresolved

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

    Google Cloud VMware Engine (GCVE) Stretched Cluster customers are experiencing zonal outages impacting network connectivity across multiple regions.

    Startede 14. juli 2026 kl. 17.00 UTC · 10h 40m

    OutageStørre hændelse
    1. 14. juli 2026 kl. 20.24 UTCresolved

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

    2. 14. juli 2026 kl. 21.31 UTCresolved

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

    3. 14. juli 2026 kl. 22.16 UTCresolved

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

    4. 14. juli 2026 kl. 23.05 UTCresolved

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

    5. 15. juli 2026 kl. 00.13 UTCresolved

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

    6. 15. juli 2026 kl. 01.15 UTCresolved

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

    7. 15. juli 2026 kl. 01.55 UTCresolved

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

    8. 15. juli 2026 kl. 03.27 UTCresolved

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

    9. 15. juli 2026 kl. 05.34 UTCresolved

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

    10. 20. juli 2026 kl. 18.31 UTCresolved

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

    11. 24. juli 2026 kl. 07.10 UTCresolved

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

    Network traffic to Google Cloud originating from Delhi, Chennai, Mumbai and surrounding areas is experiencing intermittent periods of elevated latency and possible packet loss.

    Startede 5. juni 2026 kl. 07.00 UTC · 21d 12h

    IssuesMindre hændelse
    1. 10. juni 2026 kl. 01.13 UTCresolved

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

    2. 10. juni 2026 kl. 22.25 UTCresolved

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

    3. 11. juni 2026 kl. 23.25 UTCresolved

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

    4. 12. juni 2026 kl. 22.50 UTCresolved

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

    5. 15. juni 2026 kl. 23.11 UTCresolved

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

    6. 17. juni 2026 kl. 22.36 UTCresolved

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

    7. 22. juni 2026 kl. 23.51 UTCresolved

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

    8. 23. juni 2026 kl. 22.52 UTCresolved

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

    9. 29. juni 2026 kl. 23.06 UTCresolved

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

    Vertex AI Gemini API customers experienced increased error rates when accessing the global endpoint.

    Startede 27. februar 2026 kl. 12.37 UTC · 1h 58m

    OutageStørre hændelse
    1. 27. februar 2026 kl. 16.12 UTCresolved

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

    2. 4. marts 2026 kl. 23.23 UTCresolved

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

    3. 9. marts 2026 kl. 05.25 UTCresolved

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

    We are investigating elevated error rates with multiple products in us-east1

    Startede 18. juli 2025 kl. 14.42 UTC · 2h 5m

    OutageStørre hændelse
    1. 18. juli 2025 kl. 15.54 UTCresolved

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

    2. 18. juli 2025 kl. 16.29 UTCresolved

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

    3. 18. juli 2025 kl. 16.58 UTCresolved

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

    4. 18. juli 2025 kl. 17.32 UTCresolved

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

    5. 18. juli 2025 kl. 18.03 UTCresolved

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

    6. 18. juli 2025 kl. 22.08 UTCresolved

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

    7. 22. juli 2025 kl. 13.42 UTCresolved

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