Botched Network Update Triggers 12-Hour Google Cloud VMware Engine Outage Across Three Regions

A faulty network configuration update severed inter-zone links in Google Cloud VMware Engine stretched clusters across Sydney, Melbourne, and Frankfurt for nearly 12 hours on July 14.

Verified pipeline

Sources: 5 Publisher: signed Contributor: signed Hash: 46b4b11bf1 View

Editor's Note · July 16, 2026

Correction:

The article's Overview section attributes to The Stack the claim that virtual machines 'kept running during the incident but in many cases became unreachable.' The Stack's article does not contain this specific claim in its publicly accessible text. The fact itself is accurate and is independently confirmed by Techzine, which reported that 'virtual machines continued running during the outage but became largely inaccessible,' and is consistent with Google's own incident report and SDxCentral's reporting that VMs were 'effectively isolated.'

Clarification:

The article quotes Neil Shah of Counterpoint Research as saying, in quotation marks, that the disruption stemmed from 'a routine internal network update or configuration tweak' that 'introduced routing failure across multiple zones.' In the cited Network World article, this wording is the reporter's paraphrased description of Shah's comments, not text presented in quotation marks as Shah's own words. Only a separate sentence beginning 'While most of the physical nodes...' is an actual direct quotation from Shah in the source.

Overview

A faulty network configuration update disrupted Google Cloud VMware Engine (GCVE) Stretched Cluster environments in Sydney, Melbourne, and Frankfurt for roughly 11 hours and 46 minutes on July 14, 2026, according to Google Cloud’s incident report. The outage struck a product Google markets specifically as protection against a single-zone failure, according to The Stack, which reported that virtual machines kept running during the incident but in many cases became unreachable.

What We Know

The incident began at 10:00 PDT on July 14 and was fully mitigated by 21:46 PDT the same day, according to Google Cloud’s status page, which put the total disruption at 11 hours and 46 minutes. The affected regions were Sydney (australia-southeast1), Melbourne (australia-southeast2), and Frankfurt (europe-west3), according to SDxCentral.

Only environments using stretched clusters were affected; standard GCVE deployments were unaffected, according to SDxCentral and Techzine. A stretched cluster spreads a single VMware cluster across two physical locations or availability zones so that if one site goes down, the other can take over without interruption, Techzine explained. During the outage, that cross-site link is exactly what failed: Google traced the problem to connections between the cluster zones and what it called the “witness appliance,” combined with Border Gateway Protocol (BGP) session flapping between cluster zones, which prevented cluster components from synchronizing their status, according to Google Cloud’s status page.

Google said compute and storage services continued to function and that the virtual machines themselves did not go down, according to Techzine, but SDxCentral reported that VMs on the impacted sites were “effectively isolated and left without writable data.” Google’s status page states plainly: “A network configuration update was the cause of the inter-zone network disruption.” The company resolved the incident by rolling back the faulty configuration to its last-known good value, according to Google Cloud’s status page.

Industry analysts questioned by Network World said the incident undercuts the core selling point of stretched clusters. Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting, said “Google made a network setting change that accidentally broke the connection between the two data center zones,” and added: “Stretched clusters are designed to keep applications running if one site fails. When the network connecting the two sites is disrupted, that resilience breaks down.” Neil Shah of Counterpoint Research said the disruption stemmed from “a routine internal network update or configuration tweak” that “introduced routing failure across multiple zones,” and suggested organizations that need absolute resilience for mission-critical systems consider “asynchronous geo-separation with multi-cloud deployment.”

What We Don’t Know

Google has not disclosed how many customers were affected by the outage, The Stack reported, noting that the company “did not immediately respond to questions from The Stack, including why recovery took nearly half a day.”

Analysis

SDxCentral framed the GCVE incident as part of a broader pattern of major outages traced back to routine configuration or software changes gone wrong, pointing to a Cloudflare tenant-API update that briefly knocked out Cloudflare’s own dashboard last September, a subsequent database-automation-tool failure that took down Cloudflare’s platform entirely, a software issue that disrupted Verizon’s network “at the turn of the year,” and the CrowdStrike sensor-configuration update that caused a widespread Microsoft outage. For Google Cloud customers who paid specifically for stretched-cluster resilience, the episode is a reminder that the feature’s protection against a zone failure depends on the health of the network link connecting the zones — and that a single bad configuration push on that link can take the safeguard down along with everything else.