Gemini Partial Outage - September 3, 2026

<p> Incident began at <strong>2026-09-01 07:44</strong> and ended at <strong>2026-09-01 11:52</strong> <span>(all times are <strong>US/Pacific</strong>).</span></p><div class="cBIRi14aVDP__status-update-text"><h2>Preliminary Incident Report</h2> <p>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 environment. We are working to address the root cause and prevent this from occurring in the future.</p> <p>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.</p> <p>If you have experienced impact outside of what is listed below, please reach out to Google Cloud Support using <a href="https://cloud.google.com/support">https://cloud.google.com/support</a></p> <h2>Date/Time of the Issue (All time US/Pacific)</h2> <p><strong>Incident Start</strong>: 1 September 2026 07:41</p> <p><strong>Incident End</strong>: 1 September 2026 11:52</p> <p><strong>Duration</strong>: 4 hours, 11 minutes</p> <h2>Summary</h2> <p>On Tuesday, 1 September 2026, some customers in us-central1-b experienced network service degradation and instance isolation for a duration of 4 hours and 11 minutes. To our customers whose businesses were impacted during this disruption, we sincerely apologize. 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.</p> <h2>Preliminary Root Cause</h2> <p>The immediate technical trigger for this event was the inadvertent physical disconnection of network fiber-optic cables during a routine hardware maintenance procedure. An engineer was performing a scheduled capacity upgrade on datacenter routers that support a fraction of capacity in the us-central1-b zone.</p> <p>The network architecture for each datacenter is designed with redundancy across multiple routing devices. The system is designed to be resilient to all single device or fiber-path failures, and most double- or triple-failures do not affect customer traffic. To ensure this, the devices and fiber paths are physically separated in each datacenter, with diverse power sources.</p> <p>A procedural error meant that the physical maintenance action sequentially unplugged 100% of fiber paths across all devices within 13 minutes. The nature of the error, combined with the speed of the action, prevented warnings of incorrect action reaching the engineer before complete disconnection.</p> <p>This resulted in compute capacity in the impacted zone being isolated from the network. Customers were unable to reach their virtual machines, and those virtual machines could not establish connections outside their zone.</p> <h2>Remediation</h2> <p>The issue was detected immediately by automated network loss monitoring systems as well as proactive probes, which rapidly engaged the network engineering and incident response teams.</p> <p>To mitigate the immediate customer impact, engineering teams actively moved traffic away from the impacted infrastructure, automatically shifting compatible workload traffic to healthy capacity elsewhere in the region.</p> <p>Concurrently, hardware operations technicians on site identified the disconnected optical links and physically reseated the fibers. Once the physical links were fully restored, traffic flow rates normalized and the traffic was redirected back to return the capacity to service.</p> <h2>Description of Impact</h2> <p>On Tuesday, 1 September, from 07:41 to 11:52 US/Pacific, a portion of the us-central1-b zone experienced severe network degradation and resource isolation.</p> <ul> <li> <p><strong>Multiple products affected:</strong> The network disruption to/from a portion of us-central1-b impacted multiple GCP Products for some customers in that zone.</p> </li> <li> <p><strong>Error rate:</strong> Traffic flow drop rates for resources hosted in the affected area reached 100% during the peak of the incident, resulting in unreachable virtual machines and elevated packet loss.</p> </li> </ul> <p><strong>Affected Services and Features</strong></p> <ul> <li><strong>Google Compute Engine:</strong> Inability to access virtual machines externally, and inability for VMs to reach remote resources.</li> <li><strong>Google Kubernetes Engine:</strong> Unreachable regional/zonal clusters and nodes within the affected zone, prompting delayed cluster recovery times.</li> <li><strong>Cloud Run / Google App Engine:</strong> Temporary latency spikes and pending queue aborts as backend workloads automatically evacuated and shifted to healthy capacity. A subset of workloads in the specifically impacted area experienced degradation until 11:52 US/Pacific.</li> <li><strong>Cloud SQL, AlloyDB for PostgreSQL, Cloud Spanner, Google Cloud Bigtable, Cloud Filestore:</strong> Data access and connectivity severed for instances localized strictly to the impacted infrastructure.</li> <li><strong>Virtual Private Cloud (VPC), Cloud NAT, Apigee, Google BigQuery, Google Cloud Dataflow, Looker, Google SecOps SOAR, Hybrid Connectivity, Cloud Interconnect:</strong> Elevated network packet loss, connectivity drops, and API timeouts in the impacted zone.</li> </ul> </div><hr><p>Affected products: AlloyDB for PostgreSQL, Apigee, Cloud Filestore, Cloud Run, Cloud Spanner, Google App Engine, Google BigQuery, Google Cloud Bigtable, Google Cloud Dataflow, Google Cloud SQL, Google Compute Engine, Google Kubernetes Engine, Hybrid Connectivity, Looker (Google Cloud core), Virtual Private Cloud (VPC)</p><p>Affected locations: Iowa (us-central1)</p>