Linode Outage History

Linode experienced a service issue affecting Linodes booting across all regions, impacting both regular Linode instances and Linode Kubernetes Engine (LKE) services globally. The issue prevented virtual machines from starting up properly in all of Linode's data centers worldwide. The problem was identified and resolved with a fix implementation, with the incident lasting approximately 1.1 hours.

Linode experienced global delays affecting VM cold and live migrations as well as resize operations across all regions for 1.5 hours. The issue was caused by an unexpected reboot of internal infrastructure components that failed to reinitialize properly, causing the migration queue to stall. The affected components were reinitialized, clearing the pending queue and restoring normal migration and resize functionality.

Linode experienced a connectivity issue in their NL-AMS data center that caused intermittent connection timeouts and errors for all services deployed in that location. The incident lasted 4.9 hours, during which users faced disrupted access to their deployed services. The issue was resolved after the team confirmed no customers were being impacted and connectivity had stabilized.

A connectivity issue caused by a third-party service provider affected Linode's AP-West (Mumbai) and IN-MAA (Chennai) data centers for 7.9 hours, causing users to experience intermittent connection timeouts and errors for all services in these locations. The incident was resolved by routing traffic through alternative paths while the upstream provider addressed their underlying connectivity problem.

Linode responded to the "Copy Fail" Linux kernel local privilege escalation vulnerability (CVE-2026-31431) that affected all Linux virtual machines across their global infrastructure, including compute instances, Kubernetes clusters, storage, and networking services. The vulnerability posed risks of privilege escalation and potential container escapes for customers running untrusted workloads. After a 100.5-hour investigation, Linode published detailed mitigation guidance and recommended that customers apply patches to all affected Linux systems.

Linode's Object Storage service experienced 403 (InvalidAccessKeyId) errors affecting key creation and validation across multiple data centers including US-East (Newark), EU-Central (Frankfurt), and AP-South (Singapore). The incident lasted 10 hours, during which customers were unable to access object storage and experienced connection timeouts. The service was fully restored after investigation and monitoring confirmed no additional issues were occurring.

Linode experienced connectivity issues in their Chennai (IN-MAA) data center caused by a degraded network component, resulting in intermittent delays and timeouts during peak traffic hours. The incident lasted approximately 130 hours while the team worked to replace the faulty hardware component. The issue was resolved when the network component replacement was completed.

Linode experienced a service issue affecting the Linode Kubernetes Engine (LKE) and NodeBalancer services across all major regions globally, including US, Canada, Europe, and Asia-Pacific locations. The incident impacted LKE functionality and prevented customers from creating new NodeBalancers or updating existing NodeBalancer configurations. The issue was identified and resolved after approximately 92 hours, with services returning to normal operation.

Linode experienced connectivity issues in their Frankfurt (DE-FRA-2) data center that lasted 13.4 hours. The incident affected network connectivity for services hosted in that region. The team implemented a fix and monitored the results before confirming full resolution.

Linode Kubernetes Engine Standard and Enterprise services experienced provisioning failures across all regions for 24.2 hours, preventing customers from deploying new clusters or adding new nodes to existing clusters. The issue was caused by an expired certificate which was identified and updated by the engineering team. The service was gradually restored with nodes successfully provisioning again, and the incident was fully resolved after monitoring confirmed stability.