Is Linode Down Today?

Common Linode issues

• →Object Storage 503s in specific regions
• →Linode boot stuck on Lassie restart
• →DNS propagation delays for new domains

• Service Issue - Host Job Performance Degradation - Several Regions

  resolved

  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 <a href="https://cloud.linode.com/support/tickets">open a Support ticket</a> for assistance.

  Jul 28, 2026Details →

• Connectivity Issue - Linodes in Milan, Italy

  postmortem

  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.

  Jul 20, 2026Details →

• Service Issue - Object Storage

  postmortem

  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.

  Jul 18, 2026Details →

• Connectivity Issue - US-MIA (Miami

  resolved

  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.

  Jul 16, 2026Details →

• Service Issue - Linode API/CLI

  postmortem

  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.

  Jul 14, 2026Details →