Google Cloud August 2026: fiber maintenance, a reroute that did not fire, and 2h 22m of us-west1 degradation

Timeline

What happened

Times and the 2-hour-22-minute window are taken from Google's published incident report, which gives the window in PDT. Intermediate steps are approximate where Google did not publish a minute-by-minute log; some individual products took longer than the headline window to fully drain as traffic was reintroduced in stages.

Affected Services

Selected products impacted in us-west1

Google lists 33 affected products; the grouping below is representative, not exhaustive. Because the failure was a loss of network capacity between data centers rather than a single service bug, the impact spread across compute, storage, databases, messaging, and platform tooling in the region at once.

Root Cause

Routine maintenance, then a reroute that never fired

Per Google's incident report, the disruption originated during scheduled fiber optic maintenance in us-west1. Fiber maintenance is routine and is meant to be non-disruptive because the region carries spare inter-datacenter capacity: the plan is that work on one path is absorbed by the others. On 20 August the maintenance unexpectedly compromised network capacity between data centers, and the automated systems that should have rerouted traffic onto that alternate capacity failed to do so.

That is the whole outage in one sentence: the spare capacity existed, but the automation that was supposed to shift traffic onto it did not act. With the traffic still trying to use paths that had lost bandwidth, the region tipped into congestion, and the congestion cascaded into core infrastructure services. Google describes the result as impacting both control-plane and data-plane operations, with elevated latency, provisioning failures, increased error rates, and service degradations across the 33 affected products.

Recovery came in two stages. Engineers first restored the inter-campus fiber network capacity, removing the underlying shortage. They then reintroduced production traffic to us-west1 through controlled validation stages, confirming each platform returned to normal before sending more load its way, rather than letting a sudden rush of retried requests create a second congestion event. The overall window was about 2 hours 22 minutes.

Economic Impact

No disclosed figure, and it depends on where you ran

Google published no cost for this outage, and no independent analyst issued an insured-loss estimate, as CyberCube did for the AWS October 2025 event ($38 million to $581 million). Unlike the global June 2025 Service Control failure, this event was confined to us-west1, so the honest measure of exposure turns on a single question: did your workloads run in us-west1, or did you have live capacity elsewhere?

For a business whose us-west1-dependent revenue runs at $100,000 per day, a total 2-hour-22-minute regional outage is roughly $9,900 of exposure before any failover mitigation. A business that ran active capacity in a second region and could shed us-west1 traffic would have seen a fraction of that. That gap - between the exposure and what a working failover would have cost you - is the entire business case for multi-region.

As with every provider outage, Google's SLA credit is not the number that matters. GCP returns a percentage of the affected service's monthly fee, never a percentage of your revenue, so even a maximum credit is a fraction of the business loss from the same window. See our SLA credit asymmetry analysis, and use the downtime cost calculator to apply your own revenue and architecture to a 2-hour-22-minute outage.

Architectural Lessons

Redundancy you have not tested failing over is not redundancy

The June 2025 Service Control outage taught that a global control plane is a concentration risk no in-provider multi-region deployment can insulate you from. August 2026 is the mirror image and just as important: a purely regional failure, where the redundancy that should have contained it did not engage. Google had alternate network capacity for us-west1. The reason the maintenance became an outage is that the automated reroute onto that capacity failed, so for the length of the incident the spare paths may as well not have existed.

The lesson generalises past Google. Most resilience lives in automation you never watch run: cross-zone rerouting, health-check-driven failover, capacity that is supposed to absorb a lost path. It only protects you if it actually fires under the exact condition you built it for, and the only way to know it fires is to exercise it - drain a path deliberately, fail a zone in a game day, and confirm traffic moves. Redundancy that has never been tested failing over is a hopeful assumption, not a control.

For how this event compares with the global GCP, AWS us-east-1, and Azure Front Door failures, see the AWS vs Azure vs GCP outage comparison and the full GCP outage history. For the June 2025 global control-plane failure, see the GCP June 2025 case study. For the cost-benefit math on multi-region and failover, see our business case builder.

Frequently Asked

Common Questions