Linode Status Page

May 29, 2026 · resolved May 29

Starting at around 10:07 UTC on May 29, 2026, Object Storage in London became unavailable. Affected customers were unable to access Object Storage during this time, and may have seen 500 or similar errors. This occurred as the result of an issue with a planned router upgrade. The router has since been brought back online, and we can confirm that the issue was mitigated at 10:19 UTC on May 29, 2026 and is no longer occurring. 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. If you continue to experience problems, please <a href="https://cloud.linode.com/support/tickets">open a Support ticket</a> for assistance.

May 22, 2026 · resolved May 26

We haven’t observed any additional connectivity issues in our Paris data center, and will now consider this incident resolved. If you continue to experience problems, please <a href="https://cloud.linode.com/support/tickets">open a Support ticket</a> for assistance.

May 19, 2026 · resolved May 20

On May 19, 2026, at 18:26 UTC, we identified an issue impacting the creation and re-provisioning of Linode instances using any of the four RTX PRO 6000 Blackwell \(g3-gpu-rtxpro6000-blackwell\) plans, resulting in API errors. These failures caused a denial of service for customers attempting to deploy g3-gpu-rtxpro6000-blackwell instances via the Cloud Manager or API. After the initial investigation SMEs determined that the cause of the issue was a logic error within a recent APIv4 update. Specifically, a validation check intended only for RDMA-enabled networking was incorrectly applied to standard Blackwell GPU plans. This caused the API to reject creation requests that did not meet specific RDMA configurations, even when those configurations were not required for the selected plan. With the issue identified, our engineering team developed and tested a hotfix to correct the plan-validation logic. Deployment of the fix began shortly after, and broader customer impact was mitigated as of 21:36 UTC on May 19, 2026, following successful verification in all regions. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing, and we are currently reviewing our automated testing to prevent similar recurrences.

May 16, 2026 · resolved May 16

On May 15, 2026, at 18:18 UTC, we identified an issue impacting the deployment of Linodes that relied on StackScripts \(including all newly created Linode Kubernetes Engine \(LKE\) and \(LKE-E\) nodes\), resulting in deployment failures. These deployment failures resulted in Linodes created with StackScripts to be unbootable and LKE autoscaling or recycling activity to fail. Subject matter experts determined that the cause of the issue was the removal of a credential parser during a recent update on compute hosts. This credential parser is used in the process of decoding StackScripts and its removal caused Linode deployments relying on StackScripts to fail. With the issue identified, we began to test a rollback at 01:10 UTC on May 16, 2026  and a reduction in failures was noted at 01:20 UTC. We mitigated the broader customer impact by  01:30 UTC on May 16, 2026. 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.

May 15, 2026 · resolved May 15

Starting around 04:00 UTC on May 14, 2026, Akamai identified an issue affecting Linode migration operations, including live, cold, and scheduled migrations. As a result, some customers experienced delays in migration processing, and customers undergoing certain migrations were temporarily unable to access their instances until processing resumed. The issue was caused by an unexpected restart of internal services required to process migrations. Following the restart, those services did not automatically recover as expected, which prevented migration tasks from initiating and led to a backlog of stalled operations. Akamai engineers restored the affected services, and migration processing resumed. Service was largely restored at approximately 03:15 UTC on May 15, 2026. Akamai is continuing to investigate the underlying cause of the unexpected service restart and is reviewing monitoring and recovery procedures to help prevent similar issues in the future. This summary reflects our current understanding of the incident based on available information. Our investigation is ongoing, and details may change as we learn more.