IL-0166 Linode · 2026-05-15kubernetes

A compute host update removed the credential parser used to decode StackScripts, so new Linodes and every new LKE and LKE-E node failed to boot and autoscaling and node recycling failed in all regions

Some Linode deployments rely on StackScripts, and all newly created LKE and LKE-E nodes do. Decoding a StackScript uses a credential parser on the compute hosts. A recent update on the compute hosts removed that parser, so every deployment that relied on StackScripts failed, the resulting Linodes could not boot, and LKE autoscaling and recycling broke in all regions.

After the cause was found, the team began testing a rollback at 01:10 UTC on 2026-05-16, saw failures drop at 01:20 UTC, and had mitigated the broader customer impact by 01:30 UTC. The incident was marked resolved at 01:43 UTC. The postmortem was posted on 2026-05-20 and says the investigation was still ongoing.

Severity: –
Scope: Linodes deployed with StackScripts, including all newly created LKE and LKE-E nodes, failed to deploy and boot; LKE autoscaling and node recycling failed
Users affected: –
Region: All regions; the status page lists US-East (Newark), US-Central (Dallas), US-West (Fremont), US-Southeast (Atlanta), US-IAD (Washington), US-ORD (Chicago), CA-Central (Toronto), EU-West (London), EU-Central (Frankfurt), FR-PAR (Paris), AP-South (Singapore), AP-Northeast-2 (Tokyo 2), AP-West (Mumbai), AP-Southeast (Sydney), SE-STO (Stockholm), US-SEA (Seattle), IT-MIL (Milan), JP-OSA (Osaka), IN-MAA (Chennai), ID-CGK (Jakarta), BR-GRU (São Paulo), NL-AMS (Amsterdam), US-MIA (Miami), US-LAX (Los Angeles), ES-MAD (Madrid), AU-MEL (Melbourne), GB-LON (London 2), IN-BOM-2 (Mumbai 2), SG-SIN-2 (Singapore 2), DE-FRA-2 (Frankfurt 2), JP-TYO-3 (Tokyo 3), ZA-JNB (Johannesburg), NZ-AKL (Auckland), CO-BOG (Bogota), US-DEN (Denver), DE-HAM (Hamburg), US-HOU (Houston), MY-KUL (Kuala Lumpur), FR-MRS (Marseille), MX-QRO (Queretaro), CL-SCL (Santiago), FR-PAR-2 (Paris 2), US-IAD-2 (Washington 2)
Time to detect: –
Time to resolve: 7h 12m

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.

The issue was identified at 18:18 UTC on 2026-05-15. The first status post, at 00:42 UTC on 2026-05-16, described an emerging service issue with Linodes booting across all regions.

Symptom Scale-up failure

Root cause

Root cause Faulty deployment

Component Cluster autoscaler Node pool

Contributing factor –

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

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

Action items

–

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.

Sources

https://status.linode.com/incidents/dj3h400zlydn · official-status

Related cases

IL-0020 During an EKS 1.30 upgrade the descheduler tried to reschedule every pod on the cordoned nodes at once and production workloads went downUK Ministry of Justice · 2025
same root cause · shared Node pool, Cluster autoscaler
IL-0163 An API change that slipped through a gap in automated testing made LKE clusters resize to the wrong number of nodes and added billable worker nodes to customer accountsLinode · 2023
same root cause · shared Node pool
IL-0164 An incremental Linode Kubernetes Engine production update that was missing changes from the previous release made cluster upgrades and node additions fail silentlyLinode · 2022
same root cause · shared Node pool
IL-0149 Upgrades of AKS clusters on Virtual Machine Scale Sets failed with a 'platform image is not available' error after a service update left a backend service unhealthyMicrosoft Azure · 2019
same root cause · shared Node pool

Check your cluster for this

kubegap audits a Kubernetes cluster for conditions like the ones in this case, Cluster autoscaler, Node pool among them, read-only, from Claude Code or Codex. Its checks cite public reports like this one.

Open kubegap

For AI tools and scripts

This case as JSON: https://incidentlib-api.benchlet.com/cases/IL-0166
The cases most like it: https://incidentlib-api.benchlet.com/cases/IL-0166/similar
MCP server (Streamable HTTP, no key): https://incidentlib-mcp.benchlet.com/mcp

The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.