Incident Library
Applied filters Root causeConfiguration changeSymptomLoad imbalanceFactorOverlapping failuresClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. Symptoms

    From 04:00 US/Pacific on 8 October 2026, Google Cloud Storage upload and write operations in the us-central1 region became slow and failed. Clients mostly saw HTTP 503 UNAVAILABLE errors on WriteObject operations and client-side timeouts.

    Trigger

    A configuration update to the Cloud Storage load balancing layer turned on a traffic sorting optimization that was meant to deal with local capacity constraints. The recurrence on 9 October came from an incomplete rollback of an upload planner feature.

    Root cause
    Component
    Contributing factor
    Detection

    Google engineering teams monitoring system telemetry detected the problem at 04:50 US/Pacific on 8 October, 50 minutes after it began.

    Remediation
    • Drained traffic from the most overloaded storage backend nodes
    • Deployed a configuration change that disabled the traffic sorting optimization
    • Rolled back a recent update to the metadata database service
    • Redirected traffic and drained affected storage components again during the recurrence
    • Fully reverted the load balancing configuration change, restoring capacity-aware routing
    • Returned the drained nodes to service once resource use was back to normal
    Action items
    • Validate load balancing logic changes in smaller regions before rolling them out to large, highly utilized regions
    • Make the storage load balancing enforce capacity constraints so traffic cannot bypass pre-spilling safeguards
    • Speed up internal data movement within highly utilized storage cells to absorb temporary load spikes
  2. Symptoms

    From 23:20 UTC on 9 March 2026 Azure OpenAI Service customers received HTTP 400 and HTTP 429 error responses for the GPT-5.2 model in Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central and UK South. All other GPT models kept working.

    Trigger

    An update to the Azure OpenAI GPT-5.2 model enabled feature settings meant to improve service efficiency and resilience. The model engine version running in production did not yet support those settings. The update was rolled out to the whole fleet in stages under Safe Deployment Practices.

    Root cause
    Component
    Contributing factor
    Detection

    Service monitoring detected the issue at 00:19 UTC on 10 March, about an hour after impact began. Detection was late because monitoring was set up for client-side HTTP 400 errors and not for service-side anomalies.

    Remediation
    • Rolled back the GPT-5.2 configuration in all affected regions instead of waiting for a hotfix
    • Completed the routing updates and restored full regional capacity information so traffic was spread normally again
    Action items
    • Train engineers on the operating procedures, including which scenarios can be rolled back quickly
    • Store a cached known-good version of the traffic routing details for when the capacity service cannot provide current data
    • Set thresholds for service-side HTTP 400 errors in monitoring
    • Improve anomaly detection on HTTP 4xx errors to alert on unusual error rates below the usual thresholds
    • Add signals to the deployment systems so problematic rollouts stop automatically
    • Make sure early rollout stages have enough backend model instances to catch such problems
Check your cluster for this

These 2 cases involve Database and Model inference server. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1