Linode Status

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

Starting around 23:15 UTC on June 15, 2026, some customers were unable to access the Longview graph dashboard. The investigation revealed that Linodes were unable to reach the Longview endpoint and were failing to report data. The impact was limited to reading the existing reporting data only and there was no permanent reporting data loss due to this issue. To mitigate the impact, we manually rebooted identified VM boxes to take effect and resolve Gateway errors. The impact was mitigated at 9:00 UTC on June 16, 2026, following this action. Post-mitigation, all expected data is available in the Longview graph dashboard. We 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.

The issue affecting Linode Migrations has been resolved. Resize and Migration operations should be operating as normal now.

This incident has been resolved.

The upstream issue has been resolved, and our Support phone line should now be fully functional again.

Between 22:50 UTC on June 2, 2026 and 19:00 UTC on June 3, 2026, some customers experienced intermittent performance degradation and long access times when interacting with the Compute Block Storage cluster in Newark, US. During this period, intermittent component instability triggered intensive background recovery operations. This elevated system load resulted in a temporary degradation of data redundancy, higher read/write latency, and reduced throughput for the affected volumes.  To mitigate the impact, Akamai successfully restored the affected storage drives to operation, stabilizing the cluster and eliminating active customer impact. Following this, additional actions aim to fully restore standard system redundancy. 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.

We haven't observed any additional issues with the Community Site, and will now consider this incident resolved. If you are still experiencing additional issues, please open a Support ticket for assistance.

Between 10:13 UTC and 10:22 UTC on May 29, 2026, customers using Object Storage \(OBJ\) in London experienced 5xx errors when trying to access content stored in that location. While attempting to isolate a separate packet loss issue, Akamai sequentially upgraded 2 pairs of routers. The first pair of routers was upgraded successfully, but due to human error the second router pair's upgrade command was executed before the first pair had completed route convergence. This resulted in a temporary loss of routing paths for OBJ traffic in the London datacenter. The issue was quickly detected via an automated alert, and service was restored automatically once the firmware upgrades and routing convergence completed. Akamai's Change Management Policy requires all router upgrade activities to be performed in accordance with established procedures and predefined implementation instructions. Akamai will conduct refresher training on the Change Management Policy to reinforce compliance with the required processes and ensure strict adherence going forward. 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 May 22, 2026 between approximately 09:10 and 11:30 UTC, connectivity issues were experienced in Paris \(FR-PAR3\) datacenter. During the impact window, customers may have experienced intermittent connection timeouts and errors for services deployed in the Paris datacenter. Our investigation established that connectivity to the host was affected as both of our transits in FRA3 flapped at the exact same time and that triggered high route churn which in result caused packet loss. On analyzing further on why both of our transits flapped at the exact same time, we engaged our Data Center provider and it was identified that during a planned maintenance in the data center, both operator rooms, which support network connectivity, lost power for several minutes, resulting in a complete isolation of the availability zone. 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 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.

The Linode Cloud Manager, API, and CLI will be offline for scheduled maintenance between 04:00 UTC and 05:30 UTC on June 24, 2026. During this window, running Linodes and related services will not be disrupted, but account management access and Support tickets will be unavailable. Please ensure that you complete critical or important jobs in the Cloud Manager or API before the maintenance window. We will update this status page once this event is complete and Linode customers have full access to all Linode services. Customers who need assistance from Linode Support during this time will need to call 855-454-6633 (+1-609-380-7100 outside of the United States) to contact our Support team. Please note that our Support team will not be able to assist with issues related to the Cloud Manager or API, authenticate users to their accounts, or respond to Support tickets for the duration of the maintenance window. As soon as our Support team regains access, we will answer tickets in the order they are received. Impacts on Current Linode Customers: Current Linode customers will not be able to log in to the Cloud Manager, interact with the API, or perform any administrative or management functions. This includes Create, Remove, Boot, Migrate, Back Up, Shut Down, etc. The scheduled maintenance will impact the Kubernetes API. Dynamic aspects of LKE that rely on the Linode API will also be impacted, to include items such as autoscaling, recycling, rebooting, attaching/detaching PVCs, Node Balancer provisioning, as well as the ability to create new clusters. Cluster nodes and running workloads will not be affected. Impacts on Users Trying to Create Linode Accounts / Awaiting Account Authentication: While the Linode Cloud Manager is offline during the maintenance period, we are unable to accept requests for new accounts or authenticate accounts for users awaiting full account access. Thank you for your patience and understanding.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.