Incident Library
Applied filters Root causeSoftware defectFactorNo headroomClear 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

Cases3 cases

1 to 3 of 3

  1. IL-0131 A new kind of GenerateContent request made Vertex AI prediction API servers segfault, and once enough of them restarted at the same time the serving fleet could not carry the load
    Google Cloud2024
    Symptoms

    From 12:06 US/Pacific on 12 June 2024, services built on Vertex AI Prediction began reporting failed user requests in eight regions: us-central1, asia-southeast1, europe-west3, europe-west4, us-east1, us-west1, northamerica-northeast1 and us-east4.

    High error rateHigh latencyIntermittent timeouts
    Trigger

    Starting on 8 June 2024, a new form of user request to the GenerateContent API caused intermittent segmentation faults in the Vertex Serving Prediction API servers; on 12 June the rate of such requests increased.

    Root cause
    Software defect
    Component
    Model inference serverCloud load balancer
    Contributing factor
    Partial rolloutNo headroom
    Detection

    Internal production monitoring alerted engineers to the segfaults on 10 June 2024 at 07:35 US/Pacific, before any visible customer impact; on 12 June services built on Vertex Prediction reported failing user requests.

    Remediation
    • confirmed the new failures came from the same segfault found on 10 June
    • accelerated the rollout of the fix that was already in progress, completed at 15:59 US/Pacific
    Action items
    • Ensure early signals of server binary issues are captured in production health analysis and investigated in time
    • Ensure release validation of feature changes and updates in production
    Lessons

    A crash that only some requests trigger can stay invisible while load balancers route around the restarting servers. It becomes an outage when the share of such requests grows until too many servers are restarting at once. Here the cause was known and a fix was rolling out two days before customers were affected, but the progressive rollout had not finished when the triggering traffic increased; Google's follow-up is to investigate early signals of server binary issues in time.

    View case
  2. IL-0024 Expensive cache-backed API calls and uncancelled database requests overloaded MongoDB and took the Hugging Face Hub down three times
    Hugging Face2024
    Symptoms

    At 08:45 CET on 22 April 2024 the Hugging Face Hub became unstable, and by 09:30 it was unresponsive. For most users the website was slow or could not be reached at all.

    Service outageHigh latencyDatabase overload
    Trigger

    Bursts of requests to revision endpoints that read heavily from the *_info_cache collections: a call to https://huggingface.co/api/datasets/lighteval/mmlu/revision/main rose sharply right before the first crash, and a call to https://huggingface.co/api/models/sentence-transformers/all-mpnet-base-v2/revision/main, a model with 300+ associated spaces, lined up with the crash at 21:30 on 23 April.

    Root cause
    Software defect
    Component
    Application databaseModel hubCluster autoscaler
    Contributing factor
    No headroomRetry stormOverlapping failures
    Detection

    Instability started at 08:45 on 22 April and the Hub was unresponsive by 09:30; the team followed MongoDB Atlas metrics and a MongoDB support case. The root cause was found days later from a new graph of requests per URL.

    Remediation
    • Added a firewall rule blocking all requests with a Java/* user agent
    • Disabled the quicksearch feature on the Hub
    • Scaled the MongoDB Atlas cluster by hand from tier 2 to tier 3
    • Switched the Hub to maintenance mode with a 503 page through AWS WAF and blocked incoming traffic
    • Scaled all Hub pods down to 0 and brought them back
    • Set an aggressive rate limit
    • Added timeouts to requests and reworked database queries that were slow or returned large bodies
    Action items
    • Add timeouts to requests based on their usual completion time
    • Optimise requests that took too long or returned a large body, and rework poorly designed database queries
    • Remove old unused indexes from the database
    • Build new dashboards and monitoring metrics
    • Move the *_info_cache collections to Redis
    • Make it possible to abort any database request when the client aborts theirs
    Lessons

    Finding the root cause took two to three days: the existing charts did not show it, and a per-URL request breakdown did. Not cancelling database work when a client goes away turns a strained database into a thundering herd. A close inspection of the database exposed architectural flaws and bottlenecks, such as a collection with large unused indexes, and taught the team which metrics need closer watching to anticipate crashes. Unrelated failures happening at the same time added to the stress and made restoring service harder.

    View case
  3. IL-0123 A response buffer allocated anew in a loop made OpenAI's routing layer nodes hit their memory limits and fail readiness checks on a morning with more completions than any day before, causing 502 and 503 errors across all models
    OpenAI2023
    Symptoms

    Between 5:42 AM and 7:16 AM PT on 8 November 2023 a large share of requests to OpenAI failed with 502 or 503 errors. Every model and API endpoint saw significant failures.

    High error rateService outageProbe failures
    Trigger

    A morning with dramatically more completions than any previous day pushed the routing layer nodes, which already had a chronic memory problem, past their memory limits.

    Root cause
    Software defect
    Component
    Model request routingContainer memory limit
    Contributing factor
    No alert on limitNo headroom
    Remediation
    • limited incoming traffic
    • redeployed the routing service en masse
    • ramped traffic back up slowly
    Action items
    • Pre-allocate the responseBuffer and reuse it instead of allocating a new one in a loop (3X improvement in memory and CPU usage)
    • Adjust the configured memory limits to an appropriate level so the service has significant headroom
    • Add rate limit controls to shed traffic more gracefully
    • Increase the service's capacity
    • Change alerting to catch the underlying memory behaviour before it escalates into service issues
    • Configure autoscaling for the service, which was not possible before because added capacity could hurt an upstream service
    View case
Check your cluster for this

These 3 cases involve Cloud load balancer and Cluster autoscaler. 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.

Open kubegap

By root cause1

Software defect3 cases

Component
Cloud load balancer1Cluster autoscaler1Application database1Model inference server1Container memory limit1Model hub1Model request routing1
Contributing factor
No headroom3No alert on limit1Overlapping failures1Partial rollout1Retry storm1
Organisation
Google Cloud1Hugging Face1OpenAI1
  1. IL-0131 A new kind of GenerateContent request made Vertex AI prediction API servers segfault, and once enough of them restarted at the same time the serving fleet could not carry the load
    Google Cloud2024
  2. IL-0024 Expensive cache-backed API calls and uncancelled database requests overloaded MongoDB and took the Hugging Face Hub down three times
    Hugging Face2024
  3. IL-0123 A response buffer allocated anew in a loop made OpenAI's routing layer nodes hit their memory limits and fail readiness checks on a morning with more completions than any day before, causing 502 and 503 errors across all models
    OpenAI2023