Linode outage history

Our team is investigating an issue affecting the Object Storage service in US-SEA. During this time, users may experience intermittent 5xx errors with this service.

We are continuing to investigate this issue.

The issue has been identified and a fix is being implemented.

We haven’t observed any additional issues with the Object Storage service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

Our team is investigating an emerging service issue affecting us-sea (Seattle, WA). We will share additional updates as we have more information.

At this time we have been able to correct the issue and the service has resumed normal operation.

Our team is investigating an issue affecting connectivity in our IT-MIL (Milan) data center. During this time, users may experience intermittent connection timeouts and errors for all services deployed in this data center. We will share additional updates as we have more information.

We are continuing to investigate this issue. We will share additional updates as we have more information.

We haven’t observed any additional connectivity issues in our IT-MIL (Milan) data center and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

On August 14, 2026, starting around 17:30 UTC, during an event in our IT-MIL \(Milan\) data center, multiple alerts were triggered indicating that multiple hosts in this data center became unreachable. ‌ Akamai immediately began investigating the issue and working to restore the impacted hosts. During the impact window, customers would have experienced intermittent connection timeouts and errors across all services deployed in this data center. ‌ We restored the impacted hosts and fixed the connectivity issues at 21:20 UTC on August 14, 2026. We are still investigating the cause of the failure condition. ‌ We are committed to preventing future incidents and will conduct a thorough investigation into why the hosts became unreachable, implementing measures to enhance stability and reliability. ‌ 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.

Our team is investigating an issue affecting creation of Linode Kubernetes Engine Enterprise (LKE-E) clusters in the IAD2 - Washington data center. This is a continuation of the issue reported earlier. We will share additional updates as we have more information.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

Between 17:25 UTC and 22:50 UTC on August 13, 2026, Linode Kubernetes Engine Enterprise \(LKE-E\) customers attempting to deploy G7 dedicated Linode instances in our Washington \(IAD2\) data center, received 403 provisioning error messages. Active workloads and running instances were not affected by this issue. Our investigation revealed that while total physical hardware capacity in IAD2 was sufficient, the provisioning request triggered an entitlement check failure due to an initial soft host-allocation threshold. Akamai resolved the issue by increasing the Linode-per-host limit from 5 to 20 in IAD2. Full deployment capabilities were restored and stabilized at 22:50 UTC. To prevent recurrence moving forward, we will implement dedicated alerting for entitlement and capacity issues, directly linked to response runbooks for rapid remediation. Additionally, we are building a centralized capacity overview dashboard to proactively track regional headroom. 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.

Our team is investigating an emerging service issue affecting the API in all regions. We will share additional updates as we have more information.

As of 19:30 UTC have been able to correct the issue affecting API in all regions. We will be monitoring this to ensure that the service remains stable. If you are still experiencing issues and unable to open a Support ticket , please call us at 855-454-6633 (+1-609-380-7100 Intl.), or send an email to [email protected].

We are continuing to monitor for any further issues.

This incident has been resolved.

On August 13th, 2026, at approximately 18:15 UTC, Akamai observed a brief service outage affecting [_api.linode.com_](http://api.linode.com). The total service interruption lasted for approximately 3 minutes, concluding at 18:18 UTC. Following the restoration of initial connectivity, elevated API response latency persisted through 19:06 UTC, causing slower response times and intermittent delays for customers interacting with API services. To address the performance impact, Akamai engineering teams identified a configuration discrepancy on the secondary caching infrastructure node that prevented it from absorbing the full traffic load after the failover. Engineers completed a controlled migration and moved request caching traffic back over to the primary host. Following this change, API latency rapidly decreased to normal operational levels. The initial condition was triggered by an unexpected reboot of the primary caching node's physical host. While redundant infrastructure was active, the secondary node was unable to process the failover traffic seamlessly, causing the extended performance degradation. Our engineering teams are conducting a follow-up investigation into the failover mechanisms to optimize execution speeds and align configuration settings across redundant nodes, ensuring secondary systems can handle traffic seamlessly in future events. 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.

Our team is investigating an issue affecting the Linode Kubernetes Engine (LKE). We will share additional updates as we have more information.

At this time we have been able to correct the issues affecting the LKE service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

We haven’t observed any additional issues with the LKE service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

Beginning at approximately 14:50 UTC on August 13, 2026, customers who attempted to provision Linode Kubernetes Engine Enterprise \(LKE-E\) clusters in the IAD2 data center were unable to. We identified that the issue was due to the exclusion of two components in IAD2 in a recent software version upgrade which resulted in an API mismatch. We updated the identified components to bring them in sync with the expected state. This mitigated the issue at approximately 16:00 UTC on August 13, 2026. To prevent this issue from occurring in the future, we are reviewing LKE software update processes to ensure that all included components complete version upgrades before being reintroduced to service during platform software updates. 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 August 13, 2026, between approximately 14:00-16:30 UTC, we observed intermittent failures and delays when provisioning new LKE-E clusters in the Seattle (SEA1) region. The issue affecting the LKE-E service in Seattle self-corrected at approximately 16:30 UTC, and we have not observed a recurrence since. We are actively investigating the cause. We will continue to monitor the service for stability. If you experience any problems with this service, please open a Support ticket for assistance.

On August 13, 2026, between approximately 14:30 and 16:30 UTC, Akamai experienced an issue affecting Linode Kubernetes Engine Enterprise \(LKE-E\) cluster provisioning and deployment in the Seattle \(SEA1\) region. During this time, customers attempting to create new clusters encountered failures or delays. In some cases, clusters were created but nodes were not fully provisioned, while in others, the control plane responsible for managing the cluster could not be deployed. Akamai identified the issue through customer reports, which was then validated by reproducing the failures in Seattle-based test clusters. Other regions continued to operate normally, and no existing customer workloads were impacted. By around 16:30 UTC on August 13, 2026, cluster provisioning and deployment in the Seattle region returned to normal, allowing new cluster creations to proceed without issue. After recovery, we monitored the region for several days and began a technical investigation into the service disruption. Initial findings indicate a correlation between the issue and a recent network configuration update that occurred at approximately 14:30 UTC and was rolled back at approximately 14:45 UTC. Our current hypothesis suggests that a timing conflict during the cluster provisioning process may have triggered the failures. We are continuing to investigate the technical details to confirm the root cause. We are continuing to investigate the technical details behind this issue and are working to ensure it does not recur. We will also review the scope of affected data centers and track corrective actions. 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.

Our team is investigating an upstream issue impacting Ubuntu deployments. This may impact the ability to install package and security updates on all Ubuntu systems.

We are continuing to investigate this issue. The appropriate subject matter experts are engaged. Subsequent updates around mitigation status will be posted as progress is made.

We have identified the cause of the issue, and a fix is being implemented. We will provide an update as soon as the solution is in place.

We can confirm that the issue was mitigated at 06:30 UTC on August 20, 2026 and the service has resumed normal operations.

Our team is investigating packet loss on some paths from the in-maa & in-bom-2 data centers into the US region. During this time, users may experience connection timeouts and errors with services traversing between India and United States regions. We will share additional updates as we have more information.

Our team has identified the cause of packet loss to our US data centers. We are working with our upstream provider to resolve this issue and we will provide an update as soon as the solution is in place.

We are continuing to work with our upstream provider to resolve the packet loss affecting some paths between the in-maa and in-bom-2 data centers and the US region. We will share further updates as progress continues.

At this time the upstream provider has been able to correct the issue causing packet loss on some routes from the in-maa & in-bom-2 data centers into the US region and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

On July 31, 2026, at approximately 10:00 UTC, Akamai observed intermittent network losses affecting compute users accessing US locations from our India sites \(MAA and BOM\). Customers’ services in North America, particularly the Miami data center region, experienced increased latency, intermittent connectivity issues, slower data transfers, and difficulty reaching certain applications or services. Performance was unstable, with periods of normal operation followed by disruptions. To address the issue, Akamai applied a deny-all policy to the impacted upstream provider transit link, redirecting traffic around the impacted routes. Despite this mitigation, ongoing IPv6 losses occurred due to congestion between two alternative upstream providers, impacting some users. One provider acknowledged a bottleneck in the Asia region, and the alternate provider worked to reroute traffic away from affected links.  The initial impacted service provider confirmed that two fiber cuts in Mexico caused congestion on the impacted routes. One of these fiber cuts was resolved at 23:43 UTC on July 31, 2026, and no further issues were observed following this mitigation.  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.

Our team is investigating an issue affecting the Block Storage service in several data center regions. This issue largely impacts attaching and detaching Block Storage volumes. During this time, users may experience volume attach/detach hangs, timeouts and errors with this service. We will share additional updates as we have more information.

Our team has identified the issue affecting the Block Storage service in our data centers. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

We would like to update that after additional investigation, the impact would manifest in delayed and sometimes failed host jobs, which could include many different actions on Linodes and not only impacting attaching and detaching Block Storage volumes as we mentioned in our initial update, we have updated the title to reflect the updated impact. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

A fix has been implemented and we are monitoring the results.

We haven’t observed any additional host jobs performance degradation issues, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

On 27 July 2026 at 3:30 UTC, Akamai observed an increase in errors when connecting to the Linode hosting database, primarily affecting Block Storage volume attachments. This resulted in host job failures and limited customer impact, with some users experiencing error messages and interrupted workflows. Elevated timeout rates were noted in logs for certain data center locations, coinciding with the incremental rollout of a new feature flag. Initial investigation revealed intermittent packet drops from the database proxy to client hosts during the TLS handshake. The current theory suggests that a DDoS-protection limit related to path MTU packet too big ICMP messages was reached. When the proxy sent TCP packets with a large MTU, the expected ICMP messages were dropped by Dallas gateway routers due to exceeding the configured allowable rate. This caused database proxy TCP connections to timeout to Compute Hosts. The issue was triggered by the enablement of the new feature flag, which changed the routing path and removed MTU clamping before packets reached the gateways. To mitigate the issue, Akamai rolled back the recent network change across affected Compute sites, starting at 20:50 UTC. As of 22:57 UTC, the rate of service restarts returned to pre-incident levels. Akamai is also planning a change to increase the allowable threshold for packet too big ICMP messages. 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.

Our team is currently investigating a connectivity issue affecting Linodes in the Italy (Milan) region. During this time, existing Linodes in this location may be unreachable. Please note that creating new Linodes is functioning normally and remains unaffected.

We are continuing to investigate this issue. We will provide the next update as we make progress.

Our team has identified the issue affecting connectivity in our Milan (Italy) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

At this time, we have been able to correct the issues affecting connectivity in our Milan (Italy) data center. We will be monitoring this to ensure that it remains stable. If you are still experiencing issues, please open a Support ticket for assistance.

We haven’t observed any additional connectivity issues in our Milan (Italy) data center and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

Starting around 00:33 UTC on July 20, 2026, some hosts in the Milan, Italy data center became unavailable, impacting customer access to Linodes. The investigation identified that this issue occurred during scheduled router firmware updates. While we follow a phased upgrade process to prevent service disruption, an unexpected intersection of concurrent maintenance activities led to a temporary loss of network connectivity for the affected hosts. Service was fully restored by 02:16 UTC on July 20, 2026, and all systems are now operating as expected. Internally, we are reviewing our change management and maintenance scheduling procedures to ensure better coordination and prevent similar issues in the future. 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.

Our team is investigating an issue affecting the Object Storage service. During this time, users may experience connection timeouts and errors with this service.

Our team has identified the issue affecting the Object Storage service. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

We haven’t observed any additional issues with the Object Storage service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

On July 18, 2026, between approximately 00:30 UTC and 04:00 UTC, users might have experienced 5xx errors while trying to create a new bucket in the Object Storage for the following endpoints. * [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com](http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com](http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.com](http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com](http://fr-par-1.linodeobjects.com) ‌The issue began when the infrastructure supporting Object Storage entered a degraded state across all nodes. This prevented the service from processing requests, resulting in failures during bucket creation operations. ‌To mitigate the impact, we have applied a fix at the backend system responsible for bucket creation. The impact was mitigated following this action. ‌Our subject matter experts are investigating the root cause and will take appropriate preventive actions. ‌We apologize for the impact and appreciate your patience and ongoing support. We are making configuration and operational changes to our systems to help prevent this from happening again, and remain committed to continuous improvement. ‌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.

Our team investigated an issue that affected connectivity in our US-MIA (Miami) data center between 21:20 UTC and approximately 23:28 UTC on July 15, 2026. During this window, users may have experienced degraded networking performance and packet loss for Compute services deployed in this region. The issue was resolved after we implemented a fix. We are continuing to work with our third-party service provider to confirm the root cause, as initial evidence points to a campus cross-connect (dark fiber) outage on their infrastructure.

Our team is investigating an emerging service issue affecting the API and CLI. We will share additional updates as we have more information.

Our team has identified the issue affecting the Cloud Manager and API. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

At this time we have been able to correct the issue affecting the Cloud Manager and API. We will be monitoring this to ensure that the service remains stable. If you are still experiencing issues and unable to open a Support ticket , please call us at 855-454-6633 (+1-609-380-7100 Intl.), or send an email to [email protected].

We are continuing to monitor for any further issues.

We haven't observed any additional issues with the Cloud Manager, API, or CLI, and will now consider this incident resolved. If you continue to experience issues, please contact us at 855-454-6633 (+1-609-380-7100 Intl.), or send an email to [email protected] for assistance.

On July 14, 2026, at 10:57 UTC, Akamai identified an increase in 502 errors and latency affecting customers using the Linode API, CLI, and Cloud Manager. This disruption resulted in moderate service impact, with customers reporting elevated error rates. Our initial investigation traced the issue to latency with IAM services, which was resolved, but elevated errors persisted.  Further analysis by relevant subject matter experts determined that the incident was triggered by a manual failback to the Cloud IAM primary load balancer from the secondary load balancer. This action was prompted by a warning alert indicating that the secondary load balancer was acting as the keepalived master. The manual process of starting and stopping services to initiate the failback differed from the automated process and led to a cascade of stale GRPC connections, causing increased latency and API errors. Restarting the API servers cleared the stale connections and restored normal operations. Customer impact was mitigated by approximately 13:10 UTC on July 14, 2026. To prevent recurrence, Akamai is investigating why the manual failback caused this behavior. The team is considering implementing a drain command to clear GRPC connections during failover and setting up alerts to detect stale connections for proactive intervention. However, the immediate focus remains on understanding the root cause, with alerting and automation planned for later phases. Several customers have confirmed resolution across their deployments. Akamai will continue to monitor system health and await additional customer feedback before declaring full recovery.  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.

Our team has identified an emerging service issue affecting host jobs for some hosts across all regions. Linode connectivity is *not impacted*, but some host-level jobs, such as backups or attempts to power on or off your services may be delayed. We will share additional updates as we have more information.

This incident has been resolved.

Our team is investigating an emerging service issue affecting Cloud Manager logins. We will share additional updates as we have more information.

We are continuing to investigate this issue. We will provide an update within the next 30 minutes.

At this time we have been able to correct the issue affecting the Cloud Manager logins. We will be monitoring this to ensure that the service remains stable. If you are still experiencing issues and unable to open a Support ticket , please call us at 855-454-6633 (+1-609-380-7100 Intl.), or send an email to [email protected].

We haven't observed any additional issues with the Cloud Manager logins and will now consider this incident resolved. If you continue to experience issues, please contact us at 855-454-6633 (+1-609-380-7100 Intl.), or send an email to [email protected] for assistance.

On July 9, 2026, at 15:43 UTC, customers were unable to login to [cloud.linode.com](http://cloud.linode.com) using username and password. Customers were getting "wrong password" error message.  Investigation revealed that the issue was due to an internal certificate issue. To mitigate the impact, we fixed the certificate issue on the impacted servers at 17:24 UTC on July 9, 2026. After monitoring our systems for some time, we confirmed the issue was fully resolved. Akamai will deploy a permanent fix to prevent a recurrence of the issue.

Our team is investigating an emerging service issue affecting Managed Databases across all regions. Customers may experience latency when provisioning new databases or deleting existing ones. There is no observed impact to the performance or availability of active, running databases at this time. We will provide updates as more information becomes available.

This incident has been resolved.

Our team is investigating a service issue that affects the auto configuration of networking on Linodes by Network Helper to fail. During that time, some users may have Linodes provision but appear to have no connectivity. This also can impact Linodes created by the Linode Kubernetes Engine and impact autoscaling or provisioning of clusters. Customers can still manually configure networking via the LISH console to mitigate this issue. Please see our guide on manual network configuration on a Compute Instance . We will share additional updates as we have more information.

A fix has been implemented to resolve the automated network configuration issue on Linodes using Network Helper. We recommend rebooting your Linode to restore full network functionality. We are actively monitoring the results to ensure continued stability.

We haven’t observed any additional issues with the Linode Automated Networking service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

Our team is investigating an emerging issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. During this time, users may experience connection timeouts and errors with this service. We will share additional updates as we have more information.

We are continuing to investigate this issue.

Our team has identified the issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

We are continuing to work on a fix for this issue.

At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

We haven’t observed any additional issues with the Block Storage service in Singapore Expansion, SP (sg-sin-2), and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

On June 30, 2026, between approximately 17:30 UTC and 21:45 UTC, users may have experienced connection timeouts and errors related to the Block Storage service in Singapore Expansion, SP \(sg-sin-2\). The issue began when one host in the cluster was taken down for maintenance while another host unexpectedly encountered network issues. A configuration issue also contributed to the impact. These factors led to a degraded state that affected performance and, to a limited extent, data availability. We mitigated the impact to customers at 21:45 UTC on June 30, 2026 by correcting the network, configuration and cluster issues. We apologize for the impact and appreciate your patience and ongoing support. We are making configuration and operational changes to our systems to help prevent this from happening again, and remain committed to continuous improvement. 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.

Our team is investigating an issue affecting the Cloud Pulse Metrics (ACLP Metrics), specifically impacting Managed Database Metrics reporting. The issue appears to be intermittent. We will share additional updates as we have more information.

We are continuing to investigate this issue. We will share additional updates as we have more information.

We are continuing to investigate this issue. We will provide further updates as we have more information.

We are continuing to investigate this issue.

We have not observed a recurrence of the issue affecting the Cloud Pulse Metrics (ACLP Metrics) for several hours. Our team will continue to monitor the service closely while we investigate the underlying cause. If you continue to experience problems, please open a Support ticket for assistance.

We are continuing to monitor for any further issues.

We haven’t observed any additional issues with the Cloud Pulse Metrics (ACLP Metrics) service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.