Incident Library
Applied filters Root causeSoftware defectComponentCluster autoscalerSymptomService outageClear 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-0157 After a release, new nodes could not join Linode Kubernetes Engine clusters with IP ACL enabled, so autoscaling failed on about 20 to 25 clusters
    Linode2025
    Symptoms

    From about 01:00 UTC on 2025-03-05, Linode Kubernetes Engine (LKE) clusters with IP ACL enabled failed to autoscale: new nodes could not join the cluster, and some customers had service disruptions. About 20 to 25 clusters in several regions around the world were affected; the status page lists the US-IAD (Washington), US-ORD (Chicago), US-SEA (Seattle) and IN-MAA (Chennai) LKE components.

    Scale-up failureService outage
    Trigger

    Akamai deployed the latest LKE software release.

    Root cause
    Software defect
    Component
    Cluster autoscaler
    Contributing factor
    –
    Detection

    Customers began having problems at about 01:00 UTC, and the first status post, at 06:49 UTC, said the team was investigating an LKE autoscaling problem when IP ACL is turned on.

    Remediation
    • restarted the gateway pods, which gave only short-term relief
    • rolled back the release on all affected clusters
    Action items
    • Continue investigating the root cause and take preventive actions
    Lessons

    The defect hit only clusters with IP ACL enabled, and it showed when the autoscaler tried to add nodes. Restarting the gateway pods did not hold; rolling back the release ended the incident.

    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
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 autoscaler2Application database1Model hub1
Contributing factor
No headroom1Overlapping failures1Retry storm1
Organisation
Hugging Face1Linode1
  1. IL-0157 After a release, new nodes could not join Linode Kubernetes Engine clusters with IP ACL enabled, so autoscaling failed on about 20 to 25 clusters
    Linode2025
  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