Gemini Partial Outage - September 29, 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>Addendum to Incident Report</h2> <p>This addendum extends the Detailed Description of Impact from the previous message. Though only two clusters in a datacenter in us-central1-b and us-central1-f experienced network isolation, a few regional products with a dependency on the affected datacenter were also affected. Between 07:41 and 11:52 US/Pacific on Tuesday, September 1, 2026, the following products were affected:</p> <ul> <li><strong>Compute Engine VMs</strong>: VMs running in the affected data center lost network connectivity to resources located outside of their datacenter. From a Compute Engine perspective, this incident only affected a subset of VMs in us-central1-b and us-central1-f.</li> <li><strong>Zonal and Regional Products Based on Compute Engine</strong> Products with dependencies on VMs in the affected datacenter experienced symptoms like connection timeouts or service unavailability because the underlying VMs lost network connectivity.</li> </ul> <p>Examples of products that are based on Compute Engine VMs include: Apigee, Cloud SQL, AlloyDB for PostgreSQL, Dataflow, Cloud Filestore, and Looker.</p> <ul> <li><strong>Google Kubernetes Engine (GKE)</strong>: GKE clusters whose control plane had dependencies on Compute Engine VMs in the affected clusters experienced errors and timeouts when administrators or nodes attempted to connect to the Kubernetes API server. Consequently, deployments might have been delayed, Kubernetes API operations might have failed, and new nodes might not have registered with the control plane (causing node pool operational delays).</li> <li><strong>Cloud Run and App Engine:</strong> Workloads in the us-central1 region experienced elevated serving latency, 5xx aborted request errors, and outbound connectivity degradation. To prevent severe request failures, traffic was diverted to other clusters. Diverting requests to other clusters temporarily caused elevated latency or errors in those clusters.Once the impacted cluster was restored, workload demand for these new backends created a 'thundering herd' of concurrent instance initializations. This sudden surge bypassed warm caches and overwhelmed internal file-serving tiers, extending symptoms until emergency capacity was provisioned.</li> <li><strong>Other Google APIs and Services</strong>, in us-central1 or a multi-region that includes us-central1, were affected if they had dependencies on software tasks in the affected clusters and weren't able to use software tasks in an unaffected cluster. Symptoms included connection timeouts or service unavailability. Examples of other Google APIs and services are: Google Cloud Bigtable, BigQuery, Google SecOps SOAR, Cloud Spanner, and Cloud Firestore. For some services, symptoms were limited to temporary latency spikes and service unavailability until workloads shifted to unaffected clusters.</li> <li><strong>Private Service Connect</strong>: Clients (in any region) experienced connectivity issues involving PSC endpoints with dependencies in us-central1, in specific circumstances: <ul> <li>PSC endpoints for Google APIs were affected in the same way as noted in the Google APIs and services section.</li> <li>Producer/consumer PSC endpoints were affected if the producer had load balancers or backend VMs in the affected clusters of us-central1.</li> </ul> </li> <li><strong>Hybrid Connectivity</strong>: Some Cloud Router, Cloud VPN, and Cloud Interconnect VLAN attachments in us-central1 were affected in specific circumstances: <ul> <li>Cloud Router BGP software tasks for some Cloud Routers in us-central1 experienced a Cloud Router maintenance event if their BGP software tasks were running in the affected clusters.</li> <li>Cloud VPN tunnel software tasks running in the affected clusters lost network connectivity. This caused some Cloud VPN tunnels in us-central1 to go down until a replacement tunnel task in a different cluster was assigned.</li> <li>Resources (in any region) sending packets through Cloud Interconnect VLAN attachments in us-central1 might have experienced intermittent connectivity issues in certain situations where network flows weren’t already programmed.</li> </ul> </li> <li><strong>Envoy-based load balancers and other products</strong>: Load balancers and other products that depended on managed Envoy tasks of a proxy-only subnet in us-central1 experienced increased latency or connectivity issues if enough Envoy tasks were in the affected clusters. The following products were affected: <ul> <li>Regional external application load balancers in us-central1</li> <li>Regional internal application load balancers in us-central1</li> <li>Cross-region internal application load balancers with proxies in us-central1</li> <li>Regional external proxy network load balancers in us-central1</li> <li>Regional internal proxy network load balancers in us-central1</li> <li>Cross-region internal proxy network load balancers with proxies in us-central1</li> <li>Secure Web Proxy in us-central1</li> </ul> </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>