Incident Library
Applied filters Root causeFaulty deploymentComponentNode poolOrganisationLinodeClear 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. Symptoms

    Linodes deployed with StackScripts failed to deploy and could not boot. Every newly created Linode Kubernetes Engine (LKE) and LKE-E node relies on StackScripts, so LKE autoscaling and node recycling failed as well, in all regions.

    Trigger

    A recent update on the compute hosts removed a credential parser that is used when decoding StackScripts.

    Root cause
    Component
    Contributing factor
    –
    Detection

    The issue was identified at 18:18 UTC on 2026-05-15. The first status post went up at 00:42 UTC on 2026-05-16.

    Remediation
    • tested and applied a rollback starting at 01:10 UTC on 2026-05-16, and failures dropped from 01:20 UTC
    Lessons

    Removing a credential parser from the compute hosts broke the boot of every Linode deployed with StackScripts, and every new LKE and LKE-E node is one of them, so node creation, autoscaling and node recycling stopped in all regions. The rollback reduced failures ten minutes after testing began.

  2. Symptoms

    Resizing an LKE cluster produced an incorrect number of nodes, so some customer clusters were resized in unexpected ways and the extra worker nodes were billed to the customer accounts. The clusters themselves kept functioning. Linode's first status update, at 05:07 UTC on 1 June 2023, advised customers to avoid resizing their clusters if possible.

    Trigger

    At about 16:00 UTC on 31 May 2023 a change to the API that caused LKE clusters to scale improperly was pushed to production.

    Root cause
    Component
    Contributing factor
    Detection

    The first status update, at 05:07 UTC on 1 June, said Linode had been made aware of an issue when resizing LKE clusters, about 13 hours after the change went out.

    Remediation
    • advised customers to avoid resizing their clusters
    • deployed a hotfix at 09:40 UTC on 1 June that corrected the scaling behaviour
    • left the extra worker nodes in place to avoid disrupting customer workloads
    • contacted affected customers by ticket about credit adjustments and further mitigation
    Action items
    • Audit the automated tests
    • Add pre-deployment checklist items so the same failure does not happen again
    Lessons

    An API change that alters scaling behaviour resized customer clusters and added cost while the clusters themselves kept working; Linode announced the issue about 13 hours after the change went out. Removing the extra nodes would have disrupted workloads, so the cost was handled through credits instead.

  3. Symptoms

    From about 18:30 UTC on June 15, 2022, customers of the Linode Kubernetes Engine (LKE) who tried to upgrade a cluster or add nodes saw those operations fail silently, without an error. The status page opened an investigation of an LKE issue at 19:54 UTC, and the affected list covered LKE in eleven regions.

    Trigger

    An incremental update pushed to the LKE production environment at about 18:30 UTC.

    Root cause
    Component
    Contributing factor
    –
    Detection

    The status page began investigating at 19:54 UTC, 1 hour 24 minutes after the update.

    Remediation
    • Released a follow-up LKE update at about 21:00 UTC that contained the missing changes
    Action items
    • Add steps and automation to the update process
Check your cluster for this

These 3 cases involve Node pool 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.

By root cause1