Linode incident

Emerging Service Issue - API - All Regions

Notice Resolved View vendor source →

Linode experienced a notice incident on August 13, 2026 affecting US-East (Newark) and Cloud Manager and API and 1 more component, lasting 5h 40m. The incident has been resolved; the full update timeline is below.

Started
Aug 13, 2026, 06:46 PM UTC
Resolved
Aug 14, 2026, 12:26 AM UTC
Duration
5h 40m
Detected by Pingoru
Aug 13, 2026, 06:46 PM UTC

Affected components

US-East (Newark)Cloud Manager and APIUS-Central (Dallas)US-West (Fremont)US-Southeast (Atlanta)US-IAD (Washington)US-ORD (Chicago)CA-Central (Toronto)EU-West (London)EU-Central (Frankfurt)

Update timeline

  1. investigating Aug 13, 2026, 06:46 PM UTC

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

  2. monitoring Aug 13, 2026, 07:58 PM UTC

    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].

  3. monitoring Aug 13, 2026, 07:59 PM UTC

    We are continuing to monitor for any further issues.

  4. resolved Aug 14, 2026, 12:26 AM UTC

    This incident has been resolved.

  5. postmortem Aug 17, 2026, 05:38 PM UTC

    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.