Google’s own live incident updates blamed “Border Gateway Protocol (BGP) session flapping” for the July 14, 2026 GCVE Stretched Cluster Outage — but the final root cause report, posted ten days later, says BGP and its companion protocol BFD never stopped working during the entire event.
Quick take
Google’s live updates blamed “BGP session flapping” for the July 14, 2026 GCVE Stretched Cluster outage.
The final incident report says BGP and BFD control-plane sessions stayed healthy the whole time – the real fault was a silently misrouted data path.
The outage ran from 10:00 to 20:40 US/Pacific on July 14, 2026, affecting Melbourne (australia-southeast2) and Frankfurt (europe-west3).
Third-party status trackers disagreed sharply on scope and duration for the same event, so don’t treat any single aggregator as ground truth.
GCVE Stretched Cluster Outage Timeline
The disruption started at 10:00 US/Pacific on July 14, 2026, hitting Google Cloud VMware Engine (GCVE) Stretched Cluster customers in the australia-southeast2 and europe-west3 zones, according to Google’s own Cloud Service Health incident page.
Google’s incident report, time-stamped 13:24 PDT that same day, first described “an underlying network connectivity issue affecting the infrastructure that links the zones within a stretch cluster,” and warned of synchronization problems between zones.
A later update pointed instead at “underlying inter-zone communication failures and Border Gateway Protocol (BGP) session flapping between cluster zones,” adding that the witness appliance – the component stretched clusters use to arbitrate failover – had become unreachable.
At 16:05 PDT, Google’s public messaging shifted again: “Our investigation has identified a recent configuration update that is the likely cause of the inter-zone network disruption,” with teams “working on remediation”.
Connectivity was restored by 20:40 US/Pacific on July 14, 2026, closing out an incident that Google’s own timeline shows began at 10:00 US/Pacific that same day.
Why BGP Session Flapping Was the Wrong Diagnosis
The root cause report, published July 24, 2026, tells a different story than the live updates did. A network configuration update meant to prepare the foundational network control plane for new capabilities passed Google’s initial payload validation and was deployed.
The payload was “structurally valid” but exposed a gap in the control plane’s routing logic, which caused network hosts to misprogram their routing tables. Traffic bound for the private IP address space that GCVE Stretched Clusters use for inter-zonal data tunneling was dropped.
BGP and BFD, the protocols responsible for detecting routing failures and triggering failover, run their control-plane sessions over a separate, unaffected address space. Because that space stayed healthy, BGP and BFD never flagged a problem – the failure sat entirely in the data plane.
That distinction matters operationally: a cluster can report a fully functional control plane while the specific traffic path it depends on for cross-zone synchronization is already dead. Standard BGP-based failover monitoring, on its own, would not have caught this.
What the Official Root Cause Report Changed
Google’s remediation for this specific incident was a rollback of the offending configuration change plus a reroute around the affected paths, not an architectural redesign.
Three prevention items followed: broader pre-deployment testing of GCVE network configurations, a service-level data path failover mechanism that actively probes the inter-zonal data-tunneling traffic itself instead of relying only on control-plane signals, and additional alerting aimed at this failure class.
The practical read for anyone running Stretched Cluster is that a healthy BGP session is not proof of a healthy inter-zone data path, and Google’s own prevention list amounts to an admission that its monitoring didn’t cover that gap before this incident.
Public reporting on the affected scope did not fully agree, either. The Register’s July 15 coverage listed four impacted regions – australia-southeast1, australia-southeast2, europe-west3, and northamerica-northeast2 – while Google’s own Cloud Service Health page names only two: Melbourne (australia-southeast2) and Frankfurt (europe-west3).
That gap is not resolved in the available evidence. It may reflect a wider initial customer-facing warning that Google later narrowed once the root cause was isolated, but nothing in the incident report confirms that reading, so the two-region list should be treated as the more authoritative but not necessarily complete account.
What to Verify After Any Cross-Zone Network Update
Before assuming a stretched or cross-zone deployment is resilient after a network change, this incident points to a short set of checks worth running directly against your own monitoring and Google’s status channels, not against a summary of the incident.
Watch out
Third-party outage trackers do not agree with each other or with Google on scope and duration for this incident.
One tracker mirrored the identical GCVE incident report under a “Gemini” outage label with a duration of “< 1 minute”.
Another aggregator page for the same incident still showed no vendor updates and generic guidance well after Google marked it resolved.
- Confirm whether your alerting treats BGP or BFD control-plane health as a stand-in for inter-zone data-plane reachability – this incident shows that assumption can fail silently.
- Check Google Cloud Service Health directly rather than relying solely on third-party aggregators: one aggregator mirroring this exact incident still showed no vendor updates and generic advice days after Google marked it resolved.
- If you operate Stretched Cluster in australia-southeast2 or europe-west3, verify the July 14, 2026 rollback and reroute fully restored your own configuration rather than assuming the fix applied everywhere it might be needed.
- Ask Google support directly which regions were actually affected for your account; the public region lists for this incident disagree.
By July 27, 2026, independent status trackers showed Google Cloud VMware Engine as operational, though such trackers compile user-submitted reports rather than verified vendor data and should be read as a signal to check further, not as confirmation on their own.
A separate europe-west4-a outage the same month, caused by an upstream power and cooling failure rather than a network configuration error, is a different failure mode entirely and should not be folded into this post-mortem.
The one metric worth tracking going forward is whether Google’s promised data-path probing actually ships and gets referenced in the next GCVE incident report. Until then, BGP health alone is not a sufficient signal that a stretched cluster’s cross-zone synchronization is intact.