Provider incident title: “RESOLVED: Google Cloud Storage (GCS) customers experienced elevated latencies and error rates when performing upload or write operations.”
Started
Wednesday, October 14, 2026
07:17 AM UTC
Duration
< 1 minute
total
Resolved
07:17 AM UTC
Oct 14, 2026
<p> Incident began at <strong>2026-10-08 04:00</strong> and ended at <strong>2026-10-09 09:46</strong> <span>(all times are <strong>US/Pacific</strong>).</span></p><div class="cBIRi14aVDP__status-update-text"><h2>Incident Report</h2> <h2>Date/Time of the Issue (All time US/Pacific)</h2> <p><strong>Incident First Occurrence</strong></p> <p>Incident Start: 08 October 2026 04:00</p> <p>Incident End: 08 October 2026 16:30</p> <p>Duration: 12 hours, 30 minutes</p> <p><strong>Incident Recurrence</strong></p> <p>Recurrence Start: 09 October 2026 04:05</p> <p>Recurrence End: 09 October 2026 09:46</p> <p>Duration: 5 hours, 41 minutes</p> <p><strong>Total Duration:</strong> 18 hours, 11 minutes</p> <h2>Summary</h2> <p>On Thursday, 08 October 2026, Google Cloud Storage experienced elevated write latency and write error rates while performing upload or write operations in the us-central1 region for a duration of 12 hours, 30 minutes. This was followed by a recurrence on Friday, 09 October 2026 in the us-central1-b zone for a duration of 5 hours, 41 minutes. We are taking immediate steps to ensure this doesn’t happen again.</p> <h2>Root Cause</h2> <p>Google Cloud Storage relies on a highly distributed backend architecture to process and store incoming data. During the incident window, specific storage backend nodes within the us-central1 region experienced a localized capacity shortfall due to increased traffic.</p> <p>The sequence of events leading to customer impact was as follows:</p> <ul> <li>A traffic sorting optimization configuration update to the Google Cloud Storage load balancing layer intended to address localized capacity constraints caused severe resource exhaustion on specific storage backend nodes in the affected region by inadvertently bypassing the standard capacity-aware routing logic, resulting in a severe load imbalance.</li> <li>Consequently, a small fraction of storage backend nodes in the us-central1 region received an overwhelming proportion of incoming write traffic despite having low available serving capacity. This concentration of traffic led to resource exhaustion on the affected backend servers causing backend services handling object data ingestion to begin timing out.</li> <li>Because the underlying instances could not process the high volume of requests quickly enough, the incoming upload and write requests routed to these nodes experienced elevated latency and failed to complete, resulting in errors surfaced to customers.</li> <li>Concurrently, a separate issue with the underlying database service contributed to additional metadata processing errors during a portion of the incident window.</li> <li>The recurrence of the issue on October 9 was caused by an incomplete rollback of an upload planner feature, which broke the load balancing mechanism and overloaded a few smaller storage backend nodes.</li> </ul> <h2>Remediation and Prevention</h2> <p>The issue was initially detected on 08 October 2026 at 04:50 by Google engineering teams actively monitoring system telemetry early in the incident window. </p> <p>To mitigate the issue, Google engineers executed the following step-by-step strategy:</p> <ul> <li>Engineers initially attempted to dynamically allocate additional emergency capacity to the affected region, but this was blocked by systemic regional capacity limits.</li> <li>To relieve immediate pressure, engineers selectively drained traffic from the most overloaded storage backend nodes.</li> <li>A configuration change was deployed to disable the traffic sorting optimization, significantly reducing resource overhead on the storage backend.</li> <li>For the concurrent metadata issue, engineers rolled back a recent update to the underlying metadata database service.</li> <li>While these steps provided temporary relief, a recurrence of the load imbalance required further traffic redirection and draining of affected storage components. The incident was permanently resolved when engineering fully reverted the problematic load balancing configuration change, restoring the previous capacity-aware routing behavior and allowing traffic to distribute evenly across the region.</li> </ul> <p>Once traffic levels stabilized and resource utilization returned to normal baseline levels, the previously drained nodes were restored to active service, successfully restoring normal operations.</p> <p><strong>Preventative Actions:</strong></p> <p>To ensure this issue does not recur, we are implementing the following improvements:</p> <ul> <li><strong>Safe Configuration Rollouts:</strong> We are updating our deployment protocols to ensure that load balancing logic changes are rigorously validated in alternative, smaller regions before being rolled out to larger, highly utilized regions.</li> <li><strong>Intelligent Operational Controls:</strong> We are enhancing the storage load balancing architecture to strictly enforce capacity constraints, ensuring that traffic distribution logic cannot bypass pre-spilling safeguards and route traffic to clusters lacking sufficient serving resources.</li> <li><strong>Resilient Scaling Logic:</strong> We are implementing targeted improvements to accelerate internal data movement within highly utilized storage cells, enabling the system to process data more efficiently and handle temporary load spikes with greater resilience.</li> </ul> <h2>Description of Impact</h2> <p>On 08 October 2026, from 04:00 to 16:30 in us-central1 region and 09 October 2026, from 04:05 to 09:46 in us-central1-b zone, customers experienced elevated latency and error rates during Cloud Storage upload and write operations.</p> <ul> <li><strong>Upload &amp; Write Failures:</strong> Customers primarily observed HTTP 503 UNAVAILABLE errors on WriteObject operations and client-side timeouts.</li> <li><strong>Increased Write Latency:</strong> Write operations that did succeed experienced significantly higher latencies than normal.</li> <li>Cloud Storage operations in all other regions, as well as all other Google Cloud services, remained unaffected by this specific event.</li> </ul> </div><hr><p>Affected products: Google Cloud Storage</p><p>Affected locations: Iowa (us-central1)</p>
Get alerted next time
Install Tickerr MCP — your agent auto-reports & routes around outages
When Gemini goes down again, your agent reports anonymously and instantly gets a fallback recommendation from the swarm.
Gemini is back online
View current status and uptime history
Gemini 30-day uptime: 99.9% based on Tickerr's independent monitoring checks.
This incident was sourced from Gemini's official status RSS feed. Tickerr polls RSS feeds every 10 minutes and merges updates from the same outage into a single incident timeline.
This incident lasted < 1 minute.
Tickerr monitors 90+ AI tools independently. View live Gemini status or all AI tool status.
Get alerted next time Gemini goes down
Tickerr monitors 90+ AI tools. We'll email you when an incident starts or resolves.
Weekly AI pricing & uptime digest
Price drops, new model releases, and incident summaries - every Monday. Free.
Also on Tickerr