Incident Library
Applied filters Root causeSoftware defectSymptomService outageFactorNo 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

Cases2 cases

1 to 2 of 2

  1. 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
  2. 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 2 cases involve Cluster autoscaler and Application database. 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 defect2 cases

Component
Cluster autoscaler1Application database1Container memory limit1Model hub1Model request routing1
Contributing factor
No headroom2No alert on limit1Overlapping failures1Retry storm1
Organisation
Hugging Face1OpenAI1
  1. IL-0024 Expensive cache-backed API calls and uncancelled database requests overloaded MongoDB and took the Hugging Face Hub down three times
    Hugging Face2024
  2. 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