Linode Outage History

Between approximately 09:15 UTC on April 28, 2026 and 16:54 UTC on April 29, 2026 customers could have experienced issues with their Object Storage key pairs, including: key creation and validation, Object Storage access with their keys. The impact was seen throughout multiple data centers. Our investigation established that the issue started due to a combination of factors, including: a cascading failure of a background process from one cluster to others and a reconciler appliance not running due to missing metrics and an abnormal system load that led to call failures. To resolve the issue, we have restarted the reconciler and key operations were processed for customers. To help prevent similar issues in the future, Akamai will address the cascading failure scenario, add reconciler metrics to prevent the type of outage seen as well enhance queue management to improve reconciler performance. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

On April 24, 2026, between 17:57 UTC and 23:36 UTC, NodeBalancer infrastructure experienced a service degradation caused by NodeBalancer configuration identifiers exceeding a programmed limit. This issue degraded functionality for newly created and updated NodeBalancers and rendered Linode Kubernetes Engine \(LKE\) clusters inaccessible via the UI. Any autoscaling activity, NodeBalancer creation, or modification \(such as adding or removing nodes\) triggered the generation of configuration identifiers beyond the supported threshold, resulting in further degradation. The impact extended to downstream services such as LKE. Akamai identified the root cause and deployed a fix across all data centers by 23:36 UTC on April 24, 2026. To prevent this issue from reoccurring, Akamai will investigate, document, and update related NodeBalancer behaviors where applicable. Other software load balancer \(SLB\) and NodeBalancer-related programmatic limits will also be investigated. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On April 20, 2026, approximately between 11:05 UTC and 13:10 UTC, Frankfurt \(DE-FRA-2\) data center experienced degraded connectivity and performance issues for Compute services, including Linode and Object Storage. During this time, customers in the Frankfurt region may have experienced packet loss or connectivity issues Initially, we suspected ongoing power maintenance at the datacenter to be the cause; however, this was later determined not to be impacting. Further investigation revealed the connectivity issues were affecting certain compute hosts within the site, as well as host job completion issues site wide. Akamai identified incorrect route advertisements coming from a host within the datacenter, which contributed to the disruption. The affected host was identified and isolated, which mitigated the issue and restored service stability. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

Starting at 11:45 UTC on April 16, 2026, customers using Linode Kubernetes Engine \(LKE\) and Linode Kubernetes Engine Enterprise \(LKE-E\) began to experience issues deploying LKE and LKE-E clusters and nodes. The affected customers were unable to deploy new nodes, which also prevented them from recycling nodes and autoscaling clusters. The investigation revealed that a credential expiry caused the authentication failures. Our subject matter experts \(SMEs\) created new credentials and deployed them to mitigate the impact. The issue was mitigated at around 16:27 UTC on April 16, 2026, following the credential rotation. We are continuing to investigate the root cause of what led to this credential expiry and will take appropriate preventive actions. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing, and any information herein is subject to change.

On April 15, 2026, at 16:07 UTC, we identified an issue affecting the Linode platform, where multiple hosts began experiencing Linode VM guest orchestrator service failures. This issue disrupted new Linode jobs, Linode Kubernetes Engine \(LKE\) scaling, and related operations. Customers may have noticed slow or incomplete processing of compute-related tasks, including delays or failures when resizing Linodes or clusters, deploying new resources, updating Cloud Firewall rules, or making other changes through the Cloud Manager or API. These symptoms resulted in sluggish or partially completed operations during the issue timeframe. The initial investigation traced the root cause to a problematic configuration file pertaining to the Linode VM guest orchestrator service. In response, we engaged the relevant subject matter experts to place temporary restrictive measures on fleet management services, preventing further spread of the issue. The team began reverting the problematic configuration change, and submitting code reversions to restore the correct configuration file. Between approximately 17:00 and 18:07 UTC, we worked to proactively fix impacted hosts and restore job processing. At 18:07 UTC, mitigation efforts were complete, and all hosts alerting for failed statuses had been addressed. The reverted configuration changes were pushed out to remaining compute hosts, and change propagation was verified across each data center. Additional host state tests confirmed that all necessary updates took effect. At approximately 19:40 UTC, we resumed all normal internal operations and systems. Host status monitoring continued to ensure ongoing stability. At 20:21 UTC, no further issues were identified following monitoring, and the issue was considered resolved. Work now shifts to identifying long term corrective and preventive actions. This remains a work in progress. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On March 9, 2026, at 20:02 UTC, we identified an issue impacting Dedicated CPU plan Linodes, resulting in boot failures and resource allocation errors across multiple data centers. The problem was first reported by a customer who was unable to boot a newly provisioned Dedicated CPU Linode. We began investigating the issue on March 10, 2026, and escalated it internally on March 17, 2026, after receiving additional reports. By April 14, 2026, the incident had affected 35 Dedicated CPU plan hosts across seven data centers, including Amsterdam, London, Madrid, Atlanta, Chicago, Seattle, Washington, D.C., and Osaka. The issue was traced to a known software defect that caused validation failures during the boot process, leading to insufficient resource errors and preventing fallback allocations. Subject matter experts identified a missing configuration file as the root cause of the Dedicated Linode plan issues. To address this, we implemented a workaround script and began developing a long-term platform fix. We also introduced proactive alerting to detect similar issues in the future and updated our runbook with clear mitigation steps. Temporary monitoring will remain in place until the permanent fix is deployed. The permanent platform fix is scheduled for release by the end of May as part of our regular software update cycle. With the workaround script, runbook updates, and proactive alerting in place, we mitigated the broader customer impact by 14:42 UTC on April 16, 2026. If customers experience similar issues before the May platform release, we encourage them to contact Akamai Compute Support for assistance. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

Starting around 22:55 UTC on April 9, 2026, customers were unable to access services hosted in the US-IAD \(Washington\) data center \(DC\). The investigation revealed that the issue was caused by network connectivity issues, which would have resulted in connection timeouts and/or errors for services deployed in this data center. Analysis confirmed that the disruption was triggered by a single compute host that was incorrectly configured and generated abnormal network traffic upon being powered on. To mitigate the impact, we have isolated the host, and the network stability was restored following this action. The impact was mitigated at 02:01 UTC on April 10, 2026. All management services are fully operational, and the backlog of pending host jobs has been completely processed. We will continue to investigate the root cause and will take appropriate preventive measures. We apologize for the impact and thank you for your patience and continued support. If you have further questions, please contact us at 855-454-6633 \(\+1-609-380-7100 Intl.\), or send an email to [[email protected]](mailto:[email protected]) for assistance. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing, and any information herein is subject to change.

On March 20, 2026, at approximately 10:40 UTC, the Jakarta, ID \(id-cgk\) data center experienced power fluctuations that caused outages across all services in Jakarta, with downstream impacts to services in the Singapore Expansion, SP \(sg-sin-2\), and Melbourne, AU \(au-mel\) regions. The facility switched to backup power, which triggered a simultaneous reboot of all data center network equipment and machines. Although switching to generator power should not have caused disruption, unexpected issues with the uninterrupted power supplies \(UPS\) led to outages. The data center’s facilities engineering team has identified that a transient under-voltage condition \(voltage flicker\) occurred on the utility power sources of our third-party data center. During this event, two of the data center’s UPS systems did not respond as designed, resulting in a power outage for the affected racks. The local data center team engaged a manual bypass of the affected UPS systems to generator power. Once utility power stabilized, the site transitioned off generator power and is now working with the UPS system vendor for further analysis. Content Delivery services experienced some performance degradation but recovered by 11:10 UTC. By 12:00 UTC, physical compute hosts were gradually becoming operational, but many Linode instances remained unavailable, resulting in service interruptions for workloads hosted in Jakarta. Ongoing reliance on backup power led to intermittent performance issues until full restoration. Customers in the Singapore Expansion, SP \(sg-sin-2\), and Melbourne, AU \(au-mel\) regions reported issues with Linode Kubernetes Engine \(LKE\) and Object Storage deployments. Investigation revealed that Object Storage and LKE were impacted in the cgk1, sin2, and mel1 regions, affecting the deployment of new clusters, nodes, and node pools. The incident was initially traced to under-voltage on the data center’s power sources. Akamai teams prioritized restoring data center networking, followed by Akamai products and services operating in Jakarta, ID. The data center returned to grid power at approximately 13:20 UTC. All services were restored, and the incident transitioned to monitoring at 17:28 UTC. Teams closely monitored all products and services in the affected data center and assessed the likelihood of another power event. With no issues identified, the incident was considered fully resolved at 18:27 UTC. Efforts are ongoing to address dependencies between services and data centers to improve resilience and prevent recurrences. The data center is also working with their UPS system vendor to further analyze the UPS response during the event. We are committed to making continuous improvements to our systems to prevent similar incidents in the future. We apologize for the impact and thank you for your patience and continued support. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

Between approximately 01:00 and 14:12 UTC on March 17, 2026, customers were unable to deploy new Linode Kubernetes Engine Enterprise \(LKE-E\) clusters in the Chicago \(us-ord\) region. This was caused by exceeding the allowable number of DNS records in the DNS zone used for provisioning, which prevented the creation of new records required for cluster deployment. Existing LKE-E clusters and standard LKE clusters in the region continued to operate normally. After receiving the first monitoring alert at 12:00 UTC, we investigated and identified the underlying issue. We found that DNS records associated with deleted LKE-E clusters were not being properly cleaned up, which led to a gradual buildup of unused records. This accumulation eventually reached the limit for the DNS zone, preventing new records from being created and blocking new cluster deployments. Between 13:00 and 13:20 UTC, we deleted approximately 500 obsolete domain records, which relieved the record limit and allowed new clusters to provision successfully. We restored impacted clusters to a healthy state and confirmed that deployments were functioning as expected. After a brief period to monitor these fixes, the incident was considered fully mitigated at 14:12 UTC the same day. We are continuing to clean up additional obsolete domain records and estimate that about 11,000 records will qualify for deletion based on the number of active clusters. To help prevent similar incidents and ensure reliable cluster provisioning in the future we are enhancing our record cleanup mechanisms and monitoring. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

_On March 13, 2026, between approximately 17:35 UTC and 18:54 UTC, our Washington \(US-IAD\) data center experienced connectivity issues. During this time, customers may have noticed disruptions across all services hosted in this data center._ ‌ _Our investigation revealed that three servers previously used for testing were released back to inventory without the drives being wiped. As a result, one of these servers was sent to the warehouse and later returned to the Washington data center. This led to a host broadcasting an invalid path, which caused the service disruption._ ‌ _We promptly isolated the affected host, and service began to improve around 18:54 UTC. After thorough monitoring and system checks, we confirmed that the issue was fully resolved by 19:01 UTC._ ‌ _To help prevent similar issues in the future, we will conduct a detailed investigation to determine why this host was incorrectly configured and why our network propagated the invalid path. Based on our findings, we will implement corrective measures to prevent this type of misconfiguration from recurring._ ‌ _We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence._ ‌ _This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change._

Starting around 19:15 UTC on March 12, 2026, customers were unable to create Linode Kubernetes Engine for Enterprise \(LKE-E\) clusters and unable to perform administrative tasks such as LKE-E version upgrades, Control Plane ACL changes, etc., in the Osaka data center \(JP-OSA\). The creation process was stalled indefinitely when attempting to deploy LKE-E clusters in this data center. Akamai’s investigation revealed that the issue started following a phased rollout of the LKE software release in the Osaka data center. Akamai deployed a software fix to mitigate the impact. The impact was mitigated around 01:55 UTC on March 13, 2026. The clusters that were created during the impacted window resumed their creation. Our subject matter experts will continue to investigate the root cause and will take appropriate preventive actions. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing, and any information herein is subject to change.

Beginning at 18:09 UTC on March 9, 2026, approximately 25% of Compute hosts in our IAD3 \(Washington DC\) data center experienced degraded network connectivity due to the application of an updated routing configuration intended to improve network performance. This updated router configuration was extensively tested and has been running in production in another region for several weeks without any issues. An investigation revealed that application of this change inadvertently caused loss of connectivity to these host due to a network configuration specific to the IAD3 data center. ‌ This resulted in loss of access and control of Linodes and clusters hosted on those machines until the issue was mitigated. Mitigation steps took longer than expected due to the specific networking nature of the issue and degradation of internal service visibility to impacted devices, which required additional planning to effectively apply a rollback to the prior configuration. ‌ We were able to successfully rollback the routing configuration and mitigate impact at 21:16 UTC on March 9, 2026. To prevent a reoccurrence of this issue, we are developing a new routing configuration deployment plan that avoids the identified failure modes and others inferred from our observations. ‌ This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On March 3, 2026, at approximately 20:00 UTC,, a cron job responsible for email notifications from Cloud Manager began failing due to timeouts. As the job exceeded the request timeout interval, it repeatedly failed and restarted, causing the process to resume from the beginning of its queue each time. This resulted in customers receiving multiple duplicate email notifications and some delay in those notifications. This issue only affected event-based notification emails related to host jobs such as VM shutdowns, startups, deletions, or deployments. Other notification emails set up by the customer, such as CPU usage thresholds, and the host jobs themselves remained unaffected. To address the issue, the cron job was temporarily stopped, associated services were restarted, and a processing limit was introduced to control the number of records handled per run. These actions stabilized the system, and the incident was considered mitigated at approximately 19:00 UTC on March 4, 2026. After mitigation of the root cause, a backlog of approximately 2 million pending events had to be processed, which caused further delays in notification delivery over the following days for some customers. The system worked through this backlog and gradually returned to normal processing. As of March 10, 2026, the backlog has been cleared and notification emails are being delivered as expected. Since this incident, we have already tested and implemented additional cron job optimizations to ensure consistent performance. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On March 7,2026, at approx. 10:05 UTC, the Object Storage API \(OSA\) service experienced an elevated rate of errors in one of the production clusters, during this period, customers may have experienced intermittent issues while performing operations such as loading or managing buckets, accessing keys, updating Object storage policies, or making modifications to Object Storage resources. The issue was traced to increased pressure on one of the underlying clusters following a recent configuration update. After identifying the contributing factor, the change was rolled back and service configurations were adjusted to restore normal system behavior. The issue was mitigated at 18:15 UTC, 7th March, 2026. Following the mitigation, system performance indicators improved and service stability was restored. Verification checks confirmed that request success rates returned to normal levels, system queues reduced significantly, latency stabilized and overall platform traffic appeared healthy. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On March 5, 2026, between approximately 08:45 and 10:00 UTC, we experienced connectivity issues in our Frankfurt datacenter. During the impact window, customers may have experienced intermittent connection timeouts and errors for services deployed in the Frankfurt datacenter. Our investigation established that during a planned maintenance in the data center, router cables were connected incorrectly due to human error. As a result, customers could have experienced intermittent connectivity issues during the impact window. To resolve the issue, we have corrected the data center cabling. To help prevent similar issues in the future, Akamai will reinforce maintenance procedures by ensuring technicians clearly understand the scope of work and adhere to documented maintenance instructions and verification steps during planned maintenance. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

Starting at approximately 21:00 UTC on March 4, 2026, customers utilizing NVIDIA RTX 4000 Ada GPU-backed Linodes began experiencing lockups. At first, the issue was believed to be isolated to worker nodes on the Linode Kubernetes Engine \(LKE\) platform, but was later confirmed to impact all Linodes using this hardware. Standard Compute and non-RTX4000 GPU instances were unaffected. After ruling out recent software releases, our subject matter experts isolated the root cause to a recently deployed telemetry script. During a routine system improvement initiative, our teams identified and repaired a broken, legacy monitoring script to restore a missing metric on our internal observability dashboards. While investigating why a GPU monitoring script stopped reporting correct metrics, an update was made to restore it to a working state. The script, originally written for an earlier GPU generation, issued a firmware inspection query that was not apparent from the scope of the fix being made. On the RTX 4000 Ada architecture, this class of query against an active GPU triggers a race condition in the GPU System Processor \(GSP\), causing the GPU to enter a protective lockup state and become unavailable to running workloads. We disabled the monitoring script across the GPU fleet and rebooted the nodes to mitigate the impact. The issue was fully mitigated around 17:16 UTC on March 5, 2026. We sincerely apologize for the disruption this caused to your GPU-accelerated applications and services. We will take appropriate improvement measures and prevention actions to prevent recurrence. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing, and any information herein is subject to change.

Between February 27, 2026, 11:50 UTC and February 28, 2026, 17:40 UTC, Akamai observed degraded performance, intermittent connectivity issues, and packet loss affecting Edge Delivery and Cloud services for customers in India. The issue impacted multiple Edge locations and connectivity to Mumbai and Chennai data centers. The most significant impact occurred around 12:20 UTC on February 27, with a second window of disruption in the Mumbai region between 19:45 UTC and 21:00 UTC. A recurrence was identified on February 28, 2026, at 09:17 UTC. The recurrence was partially mitigated by 09:46 UTC and fully resolved by 11:08 UTC the same day. The root cause was a chain of unexpected subsea cable outages that occurred during repair work by the third-party network provider, resulting in intermittent disruptions to internet traffic between India and Europe. During the event, traffic was rerouted through unstable alternate paths by the third party provider, resulting in packet loss and congestion. Additionally, isolation of a key network point prevented effective traffic management, leading to service interruptions. Akamai took several actions to mitigate the impact, including suspending the traffic to the affected Edge locations, temporarily removing traffic from the affected ISP provider link, and closely monitoring the platform for stability. Once the third-party provider restored normal routing, Akamai removed temporary mitigations and confirmed service stability. The incident was fully mitigated by the third party provider at 15:34 UTC on March 3, 2026, after no further recurrences were observed. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

Between February 27, 2026, 11:50 UTC and February 28, 2026, 17:40 UTC, Akamai observed degraded performance, intermittent connectivity issues, and packet loss affecting Edge Delivery and Cloud services for customers in India. The issue impacted multiple Edge locations and connectivity to Mumbai and Chennai data centers. The most significant impact occurred around 12:20 UTC on February 27, with a second window of disruption in the Mumbai region between 19:45 UTC and 21:00 UTC. A recurrence was identified on February 28, 2026, at 09:17 UTC. The recurrence was partially mitigated by 09:46 UTC and fully resolved by 11:08 UTC the same day. The root cause was a chain of unexpected subsea cable outages that occurred during repair work by the third-party network provider, resulting in intermittent disruptions to internet traffic between India and Europe. During the event, traffic was rerouted through unstable alternate paths by the third party provider, resulting in packet loss and congestion. Additionally, isolation of a key network point prevented effective traffic management, leading to service interruptions. Akamai took several actions to mitigate the impact, including suspending the traffic to the affected Edge locations, temporarily removing traffic from the affected ISP provider link, and closely monitoring the platform for stability. Once the third-party provider restored normal routing, Akamai removed temporary mitigations and confirmed service stability. The incident was fully mitigated by the third party provider at 15:34 UTC on March 3, 2026, after no further recurrences were observed. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

On February 27, 2026 between approximately 04:25 and 09:01 UTC, we experienced connectivity issues in our EU-West \(London\) datacenter. During the impact window, customers may have experienced intermittent connection timeouts and errors for all services deployed in the London datacenter. Our investigation established that traffic going via one of the ISPs was dropped within the ISP’s Autonomous System. As a result, customers could have experienced connectivity issues. To resolve the issue, we have moved traffic away from the problematic ISP’s Autonomous System. To help prevent similar issues in the future, Akamai will work with the ISP to ensure that the underlying issue within their Autonomous System is addressed before returning traffic. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

On February 21, 2026, at approximately 13:00 UTC, customers were unable to log in to [linode.com](http://linode.com) and Cloud Manager using Google Third-Party Authentication \(TPA\) across all regions. Users encountered "Access Block: Authorization Error" and "The OAuth client was deleted. Error 401: deleted\_client" messages. Our investigation found that on February 18, 2026, a client ID was deleted from the Google Console. This client ID was associated with Google Single Sign-On login, which was affected by recent changes to Akamai’s Google Cloud Platform configuration. To address the issue, we initially tried to restore the deleted configuration, but the error messages continued. We then set up a new configuration with a new client ID. After restarting all Virtual Machines, login access was fully restored at 20:24 UTC on February 21, 2026. Akamai’s team is continuing to investigate the root cause and will implement measures to prevent similar issues in the future. We apologize for any inconvenience this caused and appreciate your patience as we work to improve our services. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.