{
"vendor": "Linode",
"slug": "linode",
"platform": "statuspage",
"status_url": "https://status.linode.com",
"last_checked": "2026-09-16T12:28:20Z",
"last_state": "ok",
"history_backfilled": true,
"first_watched": "2026-09-04T07:06:16Z",
"incidents": [
{
"body": "Scheduled maintenance is currently in progress. We will provide updates as necessary.",
"first_seen": "2026-09-15T12:28:18Z",
"impact": "maintenance",
"last_seen": "2026-09-15T12:28:18Z",
"resolved_at": "2026-09-16T12:28:20Z",
"resolved_inferred": true,
"started_at": "2026-09-15T11:00:00.000Z",
"state": "maintenance",
"title": "Emergency Power Maintenance - US-ORD (Chicago)",
"updated_at": "2026-09-15T11:00:08.462Z",
"url": "https://stspg.io/5wz65mr61xjn"
},
{
"body": "Between approximately 10:15 and 12:18 UTC on September 7, 2026, customers could have experienced elevated error rates and 5xx response codes when using Cloud Manager or performing API calls.\u00a0\n\nThe investigation revealed that the issue started due to increased API load that over-utilized our database resources which in turn led to the symptoms seen by users.\n\nTo mitigate the issue, the team addressed the elevated API load issue which brought back utilization of our resources within normal ranges. Ongoing actions include monitoring platform stability, and planning enhancements to API rate limiting.\n\nThis 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.",
"first_seen": "2026-09-07T12:26:33Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-09-07T13:31:02.277Z",
"resolved_inferred": false,
"started_at": "2026-09-07T10:38:14.593Z",
"state": "postmortem",
"title": "Service Issue - Cloud Manager and API",
"updated_at": "2026-09-08T09:26:33.344Z",
"url": "https://stspg.io/s7m13yr0g1g3"
},
{
"body": "Between approximately 09:51 and 12:18 UTC on August 28, 2028, customers using the Seattle data center \\(US-SEA\\) were unable to provision new nodes or complete host jobs, whereas customers outside Seattle were unaffected.\u00a0\n\nThe investigation revealed that this was due to a Linux kernel issue that was triggered on a network router due to increased network traffic at this site while a specific BIOS setting was enabled.\u00a0 This caused system instability and affected job processing in the US-SEA region.\n\nTo mitigate the impact, the Akamai team disabled a problematic setting and rebooted the affected system, restoring service and moving the situation to a monitoring state by 12:18 UTC on August 28, 2026. As preventive actions, Akamai will audit hardware configurations to ensure the problematic feature is explicitly disabled, and implement enhanced monitoring to detect similar issues in the future.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-28T17:44:18.855Z",
"resolved_inferred": false,
"started_at": "2026-08-28T10:26:02.985Z",
"state": "postmortem",
"title": "Service Issue - US-SEA (Seattle, WA)",
"updated_at": "2026-08-28T20:36:57.097Z",
"url": "https://stspg.io/x22zq4bd4gd9"
},
{
"body": "We haven\u2019t observed any additional issues with the Object Storage service, 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-25T01:11:13.308Z",
"resolved_inferred": false,
"started_at": "2026-08-24T21:52:45.253Z",
"state": "resolved",
"title": "Service Issue - Object Storage - US-SEA",
"updated_at": "2026-08-25T01:11:13.329Z",
"url": "https://stspg.io/55j87mnk3g26"
},
{
"body": "On August 21, 2026 starting approximately at 17:23 UTC, customers using the Seattle data center \\(US-SEA\\) were unable to provision new nodes or complete host jobs, whereas customers outside Seattle were unaffected.\u00a0\n\nThe investigation revealed that this was due to a Linux kernel issue that was triggered on a network router due to increased network traffic at this site while a specific BIOS setting was enabled.\u00a0 This caused system instability and affected job processing in the US-SEA region.\n\nTo mitigate the impact, the Akamai team disabled a problematic setting and rebooted the affected system, restoring service and moving the situation to a monitoring state by 21:59 UTC on August 21, 2026. As preventive actions, Akamai will audit hardware configurations to ensure the problematic feature is explicitly disabled, and implement enhanced monitoring to detect similar issues in the future.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-21T21:59:09.975Z",
"resolved_inferred": false,
"started_at": "2026-08-21T17:23:15.830Z",
"state": "postmortem",
"title": "Service Issue - US-SEA (Seattle, WA)",
"updated_at": "2026-09-07T18:36:53.186Z",
"url": "https://stspg.io/gcbmqj8l4yxn"
},
{
"body": "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.\n\n\u200c\n\nAkamai 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.\n\n\u200c\n\nWe 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.\n\n\u200c\n\nWe 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.\n\n\u200c\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-14T21:30:41.727Z",
"resolved_inferred": false,
"started_at": "2026-08-14T20:13:30.821Z",
"state": "postmortem",
"title": "Connectivity Issue - IT-MIL (Milan) data center",
"updated_at": "2026-08-18T19:03:25.297Z",
"url": "https://stspg.io/bvhf6n00rw42"
},
{
"body": "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.\n\nOur 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.\n\nAkamai 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.\n\nTo 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-13T23:24:56.873Z",
"resolved_inferred": false,
"started_at": "2026-08-13T21:13:17.000Z",
"state": "postmortem",
"title": "Service Issue - Linode Kubernetes Engine Enterprise (LKE-E)- IAD2 (Washington)",
"updated_at": "2026-08-18T20:34:35.965Z",
"url": "https://stspg.io/80fhmqyywbpb"
},
{
"body": "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.\n\nTo 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.\n\nThe 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.\n\nOur 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-14T00:26:48.647Z",
"resolved_inferred": false,
"started_at": "2026-08-13T18:46:25.112Z",
"state": "postmortem",
"title": "Emerging Service Issue - API - All Regions",
"updated_at": "2026-08-17T17:39:07.755Z",
"url": "https://stspg.io/qwq3924zp5zr"
},
{
"body": "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.\n\nWe 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.\n\nTo 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-13T17:54:10.365Z",
"resolved_inferred": false,
"started_at": "2026-08-13T16:16:27.212Z",
"state": "postmortem",
"title": "Service Issue - Linode Kubernetes Engine (IAD2)",
"updated_at": "2026-08-17T21:30:43.296Z",
"url": "https://stspg.io/tq334j0j3tzz"
},
{
"body": "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.\n\nAkamai 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.\n\nBy 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.\n\nWe 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. \n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-13T14:00:00.000Z",
"resolved_inferred": false,
"started_at": "2026-08-13T14:00:00.000Z",
"state": "postmortem",
"title": "Service Issue - Linode Kubernetes Engine Enterprise (LKE-E) - Seattle (SEA1)",
"updated_at": "2026-08-21T13:13:45.844Z",
"url": "https://stspg.io/ks33wr32mhq8"
},
{
"body": "We can confirm that the issue was mitigated at 06:30 UTC on August 20, 2026 and the service has resumed normal operations.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-21T18:40:56.582Z",
"resolved_inferred": false,
"started_at": "2026-08-10T17:15:16.173Z",
"state": "resolved",
"title": "Upstream Issues - Ubuntu",
"updated_at": "2026-08-21T18:40:56.598Z",
"url": "https://stspg.io/jq3jz0489mdg"
},
{
"body": "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\u2019 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. \n\nTo 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.\u00a0\n\nThe 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.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-05T01:34:34.041Z",
"resolved_inferred": false,
"started_at": "2026-07-31T17:49:13.634Z",
"state": "postmortem",
"title": "Upstream Loss - Some Paths (in-maa/in-bom-2 to US Region)",
"updated_at": "2026-08-05T17:50:59.803Z",
"url": "https://stspg.io/hcgmt53ky14f"
},
{
"body": "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.\n\nInitial 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.\n\nTo 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-29T12:27:16.244Z",
"resolved_inferred": false,
"started_at": "2026-07-28T18:14:08.047Z",
"state": "postmortem",
"title": "Service Issue - Host Job Performance Degradation - Several Regions",
"updated_at": "2026-07-31T18:57:49.432Z",
"url": "https://stspg.io/s1gh58v1nl6s"
},
{
"body": "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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-20T04:10:42.256Z",
"resolved_inferred": false,
"started_at": "2026-07-20T01:52:05.576Z",
"state": "postmortem",
"title": "Connectivity Issue - Linodes in Milan, Italy",
"updated_at": "2026-07-20T06:01:49.083Z",
"url": "https://stspg.io/5yjdn7bzqpk4"
},
{
"body": "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.\n\n* [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com)\n* [us-lax-1.linodeobjects.com](http://us-lax-1.linodeobjects.com)\n* [us-iad-1.linodeobjects.com](http://us-iad-1.linodeobjects.com)\n* [us-sea-1.linodeobjects.com](http://us-sea-1.linodeobjects.com)\n* [fr-par-1.linodeobjects.com](http://fr-par-1.linodeobjects.com)\n\n\u200cThe 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.\n\n\u200cTo mitigate the impact, we have applied a fix at the backend system responsible for bucket creation. The impact was mitigated following this action.\n\n\u200cOur subject matter experts are investigating the root cause and will take appropriate preventive actions.\n\n\u200cWe 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.\n\n\u200cThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-18T04:36:16.213Z",
"resolved_inferred": false,
"started_at": "2026-07-18T03:34:19.397Z",
"state": "postmortem",
"title": "Service Issue - Object Storage",
"updated_at": "2026-07-21T15:26:51.042Z",
"url": "https://stspg.io/h46fkksq1ct3"
},
{
"body": "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.\n\n 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-16T01:24:41.783Z",
"resolved_inferred": false,
"started_at": "2026-07-16T01:24:41.719Z",
"state": "resolved",
"title": "Connectivity Issue - US-MIA (Miami",
"updated_at": "2026-07-16T01:24:41.792Z",
"url": "https://stspg.io/1t3jkqj5kfy3"
},
{
"body": "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.\u00a0\n\nFurther 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.\n\nTo 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.\n\nSeveral customers have confirmed resolution across their deployments. Akamai will continue to monitor system health and await additional customer feedback before declaring full recovery.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-14T19:26:42.772Z",
"resolved_inferred": false,
"started_at": "2026-07-14T12:21:18.341Z",
"state": "postmortem",
"title": "Service Issue - Linode API/CLI",
"updated_at": "2026-07-16T18:13:45.069Z",
"url": "https://stspg.io/sdbw18qx96mh"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-13T19:54:44.393Z",
"resolved_inferred": false,
"started_at": "2026-07-13T18:29:50.195Z",
"state": "resolved",
"title": "Service Issue - Host Jobs - All Regions",
"updated_at": "2026-07-14T15:35:08.761Z",
"url": "https://stspg.io/gzwcz2cg3zf7"
},
{
"body": "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.\u00a0\n\nInvestigation revealed that the issue was due to an internal certificate issue.\n\nTo 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.\n\nAkamai will deploy a permanent fix to prevent a recurrence of the issue.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-09T18:21:03.135Z",
"resolved_inferred": false,
"started_at": "2026-07-09T16:57:56.705Z",
"state": "postmortem",
"title": "Emerging Service Issue - Cloud Manager",
"updated_at": "2026-07-10T12:31:19.387Z",
"url": "https://stspg.io/940qf1lq7g1n"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-07T15:31:59.843Z",
"resolved_inferred": false,
"started_at": "2026-07-06T18:04:31.040Z",
"state": "resolved",
"title": "Emerging Service Issue - Managed Databases - All Regions",
"updated_at": "2026-07-07T15:31:59.865Z",
"url": "https://stspg.io/99lml1968pbb"
},
{
"body": "We haven\u2019t observed any additional issues with the Linode Automated Networking service, 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-01T18:28:17.529Z",
"resolved_inferred": false,
"started_at": "2026-07-01T17:21:49.261Z",
"state": "resolved",
"title": "Service Issue - Linode Automated Networking",
"updated_at": "2026-07-01T18:28:17.547Z",
"url": "https://stspg.io/d4c83g4fqjln"
},
{
"body": "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\\).\n\nThe 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.\n\nWe 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-30T23:22:07.070Z",
"resolved_inferred": false,
"started_at": "2026-06-30T18:54:16.380Z",
"state": "postmortem",
"title": "Service Issue - Block Storage - Singapore Expansion, SP (sg-sin-2)",
"updated_at": "2026-07-02T16:29:34.347Z",
"url": "https://stspg.io/xrqbzpswmydd"
},
{
"body": "We haven\u2019t 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 <a href=\"https://cloud.linode.com/support/tickets\">open a Support ticket</a> for assistance.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-08T12:26:09.457Z",
"resolved_inferred": false,
"started_at": "2026-06-26T17:35:04.000Z",
"state": "resolved",
"title": "Service Issue - ACLP Metrics",
"updated_at": "2026-07-08T12:26:09.472Z",
"url": "https://stspg.io/vclyqyzwb4yj"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-26T19:33:10.791Z",
"resolved_inferred": false,
"started_at": "2026-06-26T17:14:32.425Z",
"state": "resolved",
"title": "Connectivity Issue - US-IAD",
"updated_at": "2026-06-26T19:33:10.810Z",
"url": "https://stspg.io/ksy92j8jw2vz"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-25T18:42:06.946Z",
"resolved_inferred": false,
"started_at": "2026-06-25T14:33:37.133Z",
"state": "resolved",
"title": "Emerging Service Issue - Migrations",
"updated_at": "2026-06-25T18:42:06.967Z",
"url": "https://stspg.io/t4gmpl99fpgk"
},
{
"body": "On June 23, 2026, following a global software deployment, we identified an issue causing intermittent boot failures specifically for GPU Linodes. The impact was limited to instances where multiple GPU Linodes attempted to boot simultaneously. During the impact window customers could have experienced localized disruption or elevated error rates, particularly during automated node recycling or scaling events.\n\nDuring the investigation it was found that a recent software update created a conflict when multiple GPU servers tried to start up at the exact same time. The servers essentially blocked one another from loading, and our system did not automatically trigger a retry. This specific interaction only happens under heavy, simultaneous workloads, which is why it wasn't caught during our standard pre-release testing.\n\nIn order to mitigate the issue, we successfully deployed a hotfix directly to all active GPU hosts across our fleet at 20:32 UTC on June 24th, 2026. The affected systems are currently operating normally as expected.\n\nIn order to prevent this issue from happening in the future, we have developed and integrated a comprehensive fix into our upcoming software release scheduled to roll out globally over the next week. Additionally, we are actively prioritizing the procurement of dedicated GPU testing hardware for our development cloud to improve test coverage and ensure concurrent hardware workloads are fully simulated before future updates reach production.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-25T19:29:32.481Z",
"resolved_inferred": false,
"started_at": "2026-06-24T18:53:22.517Z",
"state": "postmortem",
"title": "Emerging Service Issue - GPU Instances - All Regions",
"updated_at": "2026-06-26T18:14:57.637Z",
"url": "https://stspg.io/nqpmptncw0ff"
},
{
"body": "Our upstream third-party Debian repo failed to sync with their own upstream repo chain for an unknown reason. The InRelease files for Debian packages were left to expire starting at approximately 08:12 UTC on June 24, 2026, preventing any Debian packages from getting installed. We didn't have programmatic visibility at that time to know that these files were unable to download or if the expiration date in the InRelease files had been reached. We mitigated the issue at approximately 12:35 UTC on June 24, 2026, by updating which repo we are syncing Debian packages from and purging the stale InRelease files from our cache. We are working to integrate system visibility and alerting around expiration dates of these files in addition to switching to a more reliable upstream repo, i.e. Debian's official repos.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-24T16:27:43.772Z",
"resolved_inferred": false,
"started_at": "2026-06-24T16:27:43.727Z",
"state": "postmortem",
"title": "Service Issue - Debian Package Availability",
"updated_at": "2026-06-24T17:45:23.940Z",
"url": "https://stspg.io/jkjdyn87l4ny"
},
{
"body": "On June 16, 2026 Akamai investigated an\u00a0 instance of performance degradation and connectivity slowness observed affecting applications within the Miami compute environment. This event occurred between around 13:37 UTC and 14:20 UTC on June 16, 2026.\u00a0 The Investigation revealed a configuration change on an Akamai device in Miami triggered an underlying vendor software defect within the routing platform's operating system.\u00a0 Actions were taken to mitigate the impact and restore intended routing paths.\n\nTo prevent any further recurrence, we have temporarily suspended related configuration changes.\n\nRoot Cause: During a routine, scheduled configuration update to an aggregated network link, an underlying vendor software defect within the routing platform's operating system was triggered.\n\nWhile the configuration change itself was standard and correct, the software bug caused the router to incorrectly process internal MPLS \\(Multiprotocol Label Switching\\) routing tables. Instead of applying changes only to the targeted link, the software inadvertently cleared the routing instructions for unrelated network interfaces. This unintended removal of routing paths led to the subsequent traffic disruption.\n\nWe 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-16T17:18:40.237Z",
"resolved_inferred": false,
"started_at": "2026-06-16T14:29:21.699Z",
"state": "postmortem",
"title": "Emerging Service Issue - Networking - US-MIA (Miami)",
"updated_at": "2026-06-22T18:54:54.515Z",
"url": "https://stspg.io/9dz2yytyr12x"
},
{
"body": "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.\n\nTo 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-16T13:13:59.984Z",
"resolved_inferred": false,
"started_at": "2026-06-16T08:56:14.630Z",
"state": "postmortem",
"title": "Service Issue: Longview",
"updated_at": "2026-06-19T05:10:04.877Z",
"url": "https://stspg.io/4r0r9nzw1679"
},
{
"body": "The issue affecting Linode Migrations has been resolved. Resize and Migration operations should be operating as normal now.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-16T06:06:44.157Z",
"resolved_inferred": false,
"started_at": "2026-06-16T03:44:25.474Z",
"state": "resolved",
"title": "Emerging Service Issue - Linode Migrations",
"updated_at": "2026-06-16T06:06:44.171Z",
"url": "https://stspg.io/kxm1gxmkzs4x"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-05T14:58:06.090Z",
"resolved_inferred": false,
"started_at": "2026-06-05T14:23:04.843Z",
"state": "resolved",
"title": "Emerging Service Issue - LKE Enterprise - All Regions",
"updated_at": "2026-06-05T14:58:06.109Z",
"url": "https://stspg.io/h8tpt4ycws7m"
},
{
"body": "The upstream issue has been resolved, and our Support phone line should now be fully functional again.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-04T15:51:36.666Z",
"resolved_inferred": false,
"started_at": "2026-06-03T14:22:17.991Z",
"state": "resolved",
"title": "Emerging Service Issue - Support Phone Line",
"updated_at": "2026-06-04T15:51:36.682Z",
"url": "https://stspg.io/vxkqxg5q7xrr"
},
{
"body": "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.\u00a0\n\nTo 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-04T09:11:58.023Z",
"resolved_inferred": false,
"started_at": "2026-06-03T08:58:08.085Z",
"state": "postmortem",
"title": "Service Issue - Block Storage Newark, US",
"updated_at": "2026-06-04T12:56:31.821Z",
"url": "https://stspg.io/yy6wrsdk0ggj"
},
{
"body": "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 <a href=\"https://cloud.linode.com/support/tickets\">open a Support ticket</a> for assistance.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "maintenance",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-08T19:35:20.976Z",
"resolved_inferred": false,
"started_at": "2026-06-02T01:26:10.199Z",
"state": "resolved",
"title": "Linode Community Maintenance",
"updated_at": "2026-06-08T19:35:30.679Z",
"url": "https://stspg.io/pgm6glmcjtkn"
},
{
"body": "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.\n\nThe issue was quickly detected via an automated alert, and service was restored automatically once the firmware upgrades and routing convergence completed.\n\nAkamai'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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-29T18:23:03.129Z",
"resolved_inferred": false,
"started_at": "2026-05-29T18:23:03.082Z",
"state": "postmortem",
"title": "Service Issue - Object Storage",
"updated_at": "2026-06-08T09:14:10.869Z",
"url": "https://stspg.io/g2r7m3pd2s6z"
},
{
"body": "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.\n\nOur 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.\n\nWe 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.\n\n\u00a0This 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-26T06:15:25.625Z",
"resolved_inferred": false,
"started_at": "2026-05-22T11:22:31.923Z",
"state": "postmortem",
"title": "Service Issue - Paris (FR-PAR3)",
"updated_at": "2026-06-05T11:02:17.026Z",
"url": "https://stspg.io/3k629vrcrvvf"
},
{
"body": "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.\n\nAfter 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.\n\nWith 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-20T00:27:36.575Z",
"resolved_inferred": false,
"started_at": "2026-05-19T19:48:40.689Z",
"state": "postmortem",
"title": "Emerging Service Issue - GPU Deployment",
"updated_at": "2026-05-25T17:36:04.292Z",
"url": "https://stspg.io/dmz24zjbxfj5"
},
{
"body": "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.\n\nSubject 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.\n\nWith the issue identified, we began to test a rollback at 01:10 UTC on May 16, 2026\u00a0 and a reduction in failures was noted at 01:20 UTC. We mitigated the broader customer impact by\u00a0 01:30 UTC on May 16, 2026.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-16T01:43:19.609Z",
"resolved_inferred": false,
"started_at": "2026-05-16T00:42:02.823Z",
"state": "postmortem",
"title": "Service Issue - [Linodes and Linode Kubernetes Engine (LKE)] - [All Regions]",
"updated_at": "2026-05-20T21:10:19.344Z",
"url": "https://stspg.io/1ch8htmrzqgx"
},
{
"body": "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.\n\nThe 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.\n\nAkamai engineers restored the affected services, and migration processing resumed. Service was largely restored at approximately 03:15 UTC on May 15, 2026.\n\nAkamai 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.\n\nThis summary reflects our current understanding of the incident based on available information. Our investigation is ongoing, and details may change as we learn more.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-15T03:51:39.039Z",
"resolved_inferred": false,
"started_at": "2026-05-15T02:24:01.000Z",
"state": "postmortem",
"title": "Investigating - Linode VM Migration Delays (All Regions)",
"updated_at": "2026-05-15T06:32:45.788Z",
"url": "https://stspg.io/szvnnz2w3pr9"
},
{
"body": "We have completed our investigation and response to the \"DirtyFrag\" (CVE-2026-43500, CVE-2026-43284) and \"Fragnesia\" (CVE-2026-46300) vulnerabilities. We have published documentation articles with detailed guidance on available mitigations and recommended actions for affected systems. Customers can find more information and step-by-step instructions here: \n\nhttps://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/   \nhttps://www.linode.com/docs/guides/dirty-frag-mitigation/ \n\nWe encourage all customers to review the article and apply the appropriate mitigations to their environments. If you have questions or need assistance, please contact us at 855-454-6633 (+1-609-380-7100 Intl.) or email support@linode.com for assistance.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-06T14:42:39.605Z",
"resolved_inferred": false,
"started_at": "2026-05-13T21:02:16.879Z",
"state": "resolved",
"title": "[Fragnesia] Linux Privilege Escalation Vulnerability",
"updated_at": "2026-07-06T14:42:39.638Z",
"url": "https://stspg.io/bvtxz5p5063d"
},
{
"body": "We haven\u2019t observed any additional connectivity issues in our NL-AMS 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-13T14:37:33.250Z",
"resolved_inferred": false,
"started_at": "2026-05-13T09:42:38.598Z",
"state": "resolved",
"title": "Connectivity Issue - NL-AMS",
"updated_at": "2026-05-13T14:37:33.266Z",
"url": "https://stspg.io/bg3nyt3bs4v8"
},
{
"body": "Between May 12 and May 14, 2026, Akamai Cloud Pulse \\(ACLP\\) experienced two related service interruptions that temporarily disrupted the ingestion and display of telemetry metrics specifically for Managed Databases.\n\n* Window 1: May 12, 23:15 UTC \u2013 May 13, 00:11 UTC\n* Window 2: May 14, 06:47 UTC \u2013 07:33 UTC\n\nDuring these windows, customers were unable to view Managed Database performance metrics within the Akamai Cloud Manager dashboards or retrieve them via external API and Collector streams. Metric-based alerting for Managed Databases was also impaired during both impact windows. We are currently evaluating whether the metrics data missing from these windows can be successfully backfilled.\n\nRemark: Metrics for other services, as well as the Log function, were unaffected and operated normally. Furthermore, this incident was strictly limited to the observability reporting layer. The performance, availability, and data integrity of customers\u2019 underlying Managed Databases were never impacted.\n\nThe disruption was caused by a cascading failure initiated by a brief network routing issue.\n\nDuring the initial event, a localized network disruption caused a small percentage of metrics traffic to fail to reach our processing endpoints. While the network disruption was brief, the accumulated backlog of automatic retries from the telemetry sender's built-in retry mechanism created a sudden, massive spike in traffic against the ingest endpoint.\u00a0\n\nThis \"retry storm\" overloaded the specific downstream message-queuing infrastructure responsible for processing and storing Managed Database telemetry. The processing pipeline was unable to handle the surge, causing the components to fail and leading to the complete loss of DBaaS ingestion \\(Window 1\\). The degraded performance observed two days later \\(Window 2\\) was the result of a separate, independent infrastructure incident within our telemetry partner's message-queuing service, entirely unrelated to the initial network disruption.\u00a0\n\nTo mitigate the issue, our engineering teams, working alongside our telemetry infrastructure partner, intervened to scale up the processing pipeline's configuration to absorb and clear the accumulated retry backlog. Following these actions, Managed Database metrics ingestion returned to normal levels.\n\nThis summary reflects our current understanding of the incident based on available information. Our investigation is ongoing, and details may change as we learn more.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-12T23:15:00.000Z",
"resolved_inferred": false,
"started_at": "2026-05-12T21:00:00.000Z",
"state": "postmortem",
"title": "Service Issue - ACLP Logs",
"updated_at": "2026-05-18T09:44:02.303Z",
"url": "https://stspg.io/17f3j6n2v5s7"
},
{
"body": "On May 12, 2026, at approximately 14:50 UTC, Akamai began experiencing congestion and packet loss affecting traffic between India and Europe over Internet Service Provider network paths servicing our Mumbai and Chennai data centers. Customers may have seen intermittent connection timeouts and errors in the affected regions.\n\nThe issue was due to congestion on transit paths between India and Europe. Akamai worked with the involved Internet Service Providers and their upstream providers to identify the cause. To mitigate the impact, Akamai redirected traffic away from the affected paths, stabilizing service while the investigation continued.\n\nService was restored at the Mumbai data center at 19:23 UTC on May 12, 2026, and at the Chennai data center at 00:25 UTC on May 13, 2026.\n\nAkamai will continue working with the involved Internet Service Providers to address the underlying congestion and help prevent recurrence.\n\nThis summary reflects our current understanding of the incident based on available information. Our investigation is ongoing, and details may change as we learn more.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-13T01:02:00.790Z",
"resolved_inferred": false,
"started_at": "2026-05-12T17:12:30.000Z",
"state": "postmortem",
"title": "Connectivity Issue - AP-West (Mumbai) and IN-MAA (Chennai)",
"updated_at": "2026-05-14T15:11:06.882Z",
"url": "https://stspg.io/j7tqwgf380d5"
},
{
"body": "We have completed our investigation and response to the \"DirtyFrag\" (CVE-2026-43500, CVE-2026-43284) and \"Fragnesia\" (CVE-2026-46300) vulnerabilities. We have published documentation articles with detailed guidance on available mitigations and recommended actions for affected systems. Customers can find more information and step-by-step instructions here: \n\nhttps://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/   \nhttps://www.linode.com/docs/guides/dirty-frag-mitigation/ \n\nWe encourage all customers to review the article and apply the appropriate mitigations to their environments. If you have questions or need assistance, please contact us at 855-454-6633 (+1-609-380-7100 Intl.) or email support@linode.com for assistance.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-06T14:41:20.505Z",
"resolved_inferred": false,
"started_at": "2026-05-08T13:40:34.670Z",
"state": "resolved",
"title": "[DirtyFrag] Linux Privilege Escalation Vulnerability",
"updated_at": "2026-07-06T14:41:20.539Z",
"url": "https://stspg.io/nffg57tmk72n"
},
{
"body": "We have completed our investigation and response to the \u201cCopy Fail\u201d Linux kernel local privilege escalation vulnerability (CVE-2026-31431). We have published a documentation article with detailed guidance on available mitigations and recommended actions for affected systems. Customers can find more information and step-by-step instructions here: https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/\n\nWe encourage all customers to review the article and apply the appropriate mitigations to their environments. If you have questions or need assistance, please contact us at 855-454-6633 (+1-609-380-7100 Intl.) or email support@linode.com for assistance.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-05T22:19:10.243Z",
"resolved_inferred": false,
"started_at": "2026-05-01T17:51:06.357Z",
"state": "resolved",
"title": "(Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability [CVE-2026-31431]",
"updated_at": "2026-05-05T22:19:10.278Z",
"url": "https://stspg.io/l5l21bbt8dp8"
},
{
"body": "Between approximately 09:15 UTC on April 28, 2026 and 16:54 UTC on April 29, 2026 customers could have experienced issues with their Object Storage key pairs, including: key creation and validation, Object Storage access with their keys. The impact was seen throughout multiple data centers.\n\nOur investigation established that the issue started due to a combination of factors, including: a cascading failure of a background process from one cluster to others and a reconciler appliance not running due to missing metrics and an abnormal system load that led to call failures.\n\nTo resolve the issue, we have restarted the reconciler and key operations were processed for customers.\n\nTo help prevent similar issues in the future, Akamai will address the cascading failure scenario, add reconciler metrics to prevent the type of outage seen as well enhance queue management to improve reconciler performance.\n\nWe 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-29T19:19:35.976Z",
"resolved_inferred": false,
"started_at": "2026-04-29T09:22:02.620Z",
"state": "postmortem",
"title": "Object Storage Key creation and validation failing with error 403 in multiple data centers",
"updated_at": "2026-04-30T13:06:28.590Z",
"url": "https://stspg.io/6l0lwbllbvdp"
},
{
"body": "At approximately 3:30 UTC on April 28, 2026, we experienced a router failure in our Chennai data center, which, when paired with a separate network hardware component temporarily operating at a reduced capacity, resulted in intermittent delays or timeouts for Compute customers accessing Linodes and other resources in the Chennai \\(MAA\\) region during peak traffic hours \\(~09:00UTC - 18:00UTC\\) on April 28, 2026.\n\nAt 11:40UTC on April 29, 2026, we unthrottled the constrained network component, resulting in enough regional capacity to effectively mitigate the risk for reoccurrence of customer impact during peak regional traffic hours going forward.\n\nAt 12:11 UTC on May 2, 2026, we successfully replaced the degraded router and brought the new router online, restoring full capacity to the region.\n\nWe will work with our hardware vendor partner to understand the failure mode of the router and ensure any potential preventative actions are noted and taken proactively.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-04T03:43:08.518Z",
"resolved_inferred": false,
"started_at": "2026-04-28T17:17:58.039Z",
"state": "postmortem",
"title": "Service Issue - Connectivity Issues - Chennai (IN-MAA)",
"updated_at": "2026-05-06T19:33:54.093Z",
"url": "https://stspg.io/6g9f4gysldrm"
},
{
"body": "On April 24, 2026, between 17:57 UTC and 23:36 UTC, NodeBalancer infrastructure experienced a service degradation caused by NodeBalancer configuration identifiers exceeding a programmed limit. This issue degraded functionality for newly created and updated NodeBalancers and rendered Linode Kubernetes Engine \\(LKE\\) clusters inaccessible via the UI.\n\nAny autoscaling activity, NodeBalancer creation, or modification \\(such as adding or removing nodes\\) triggered the generation of configuration identifiers beyond the supported threshold, resulting in further degradation. The impact extended to downstream services such as LKE.\n\nAkamai identified the root cause and deployed a fix across all data centers by 23:36 UTC on April 24, 2026.\n\nTo prevent this issue from reoccurring, Akamai will investigate, document, and update related NodeBalancer behaviors where applicable. Other software load balancer \\(SLB\\) and NodeBalancer-related programmatic limits will also be investigated.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-28T15:16:20.898Z",
"resolved_inferred": false,
"started_at": "2026-04-24T19:27:45.261Z",
"state": "postmortem",
"title": "Service Issue - Linode Kubernetes Engine (LKE)",
"updated_at": "2026-04-30T19:42:15.806Z",
"url": "https://stspg.io/qsprmmplgfyk"
},
{
"body": "On April 20, 2026, approximately between 11:05 UTC and 13:10 UTC, Frankfurt \\(DE-FRA-2\\) data center experienced degraded connectivity and performance issues for Compute services, including Linode and Object Storage. During this time, customers in the Frankfurt region may have experienced packet loss or connectivity issues\n\nInitially, we suspected ongoing power maintenance at the datacenter to be the cause; however, this was later determined not to be impacting. Further investigation revealed the connectivity issues were affecting certain compute hosts within the site, as well as host job completion issues site wide. Akamai identified incorrect route advertisements coming from a host within the datacenter, which contributed to the disruption. The affected host was identified and isolated, which mitigated the issue and restored service stability.\n\nWe 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-21T01:08:34.904Z",
"resolved_inferred": false,
"started_at": "2026-04-20T11:49:15.000Z",
"state": "postmortem",
"title": "Emerging Service Issue - Connectivity issues in Frankfurt (DE-FRA-2)",
"updated_at": "2026-04-21T14:11:34.043Z",
"url": "https://stspg.io/bg6pp69hkwm5"
},
{
"body": "Starting at 11:45 UTC on April 16, 2026, customers using Linode Kubernetes Engine \\(LKE\\) and Linode Kubernetes Engine Enterprise \\(LKE-E\\) began to experience issues deploying LKE and LKE-E clusters and nodes. The affected customers were unable to deploy new nodes, which also prevented them from recycling nodes and autoscaling clusters. The investigation revealed that a credential expiry caused the authentication failures.\n\nOur subject matter experts \\(SMEs\\) created new credentials and deployed them to mitigate the impact. The issue was mitigated at around 16:27 UTC on April 16, 2026, following the credential rotation.\n\nWe are continuing to investigate the root cause of what led to this credential expiry and will take appropriate preventive actions.\n\nWe 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.\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-17T13:30:19.902Z",
"resolved_inferred": false,
"started_at": "2026-04-16T13:20:32.773Z",
"state": "postmortem",
"title": "Linode Kubernetes Engine Standard and Enterprise provisioning failures in all regions",
"updated_at": "2026-04-21T02:25:27.221Z",
"url": "https://stspg.io/hmhy69jd28vb"
},
{
"body": "On April 15, 2026, at 16:07 UTC, we identified an issue affecting the Linode platform, where multiple hosts began experiencing Linode VM guest orchestrator service failures. This issue disrupted new Linode jobs, Linode Kubernetes Engine \\(LKE\\) scaling, and related operations. Customers may have noticed slow or incomplete processing of compute-related tasks, including delays or failures when resizing Linodes or clusters, deploying new resources, updating Cloud Firewall rules, or making other changes through the Cloud Manager or API. These symptoms resulted in sluggish or partially completed operations during the issue timeframe.\u00a0\n\nThe initial investigation traced the root cause to a problematic configuration file pertaining to the Linode VM guest orchestrator service. In response, we engaged the relevant subject matter experts to place temporary restrictive measures on fleet management services, preventing further spread of the issue. The team began reverting the problematic configuration change, and submitting code reversions to restore the correct configuration file. Between approximately 17:00 and 18:07 UTC, we worked to proactively fix impacted hosts and restore job processing.\u00a0\n\nAt 18:07 UTC, mitigation efforts were complete, and all hosts alerting for failed statuses had been addressed. The reverted configuration changes were pushed out to remaining compute hosts, and change propagation was verified across each data center. Additional host state tests confirmed that all necessary updates took effect. At approximately 19:40 UTC, we resumed all normal internal operations and systems. Host status monitoring continued to ensure ongoing stability. At 20:21 UTC, no further issues were identified following monitoring, and the issue was considered resolved. Work now shifts to identifying long term corrective and preventive actions. This remains a work in progress.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-06T15:32:04Z",
"resolved_at": "2026-04-15T20:21:03.110Z",
"resolved_inferred": false,
"started_at": "2026-04-15T16:57:17.585Z",
"state": "postmortem",
"title": "Service Issue - Cloud Manager and API",
"updated_at": "2026-04-17T19:41:37.852Z",
"url": "https://stspg.io/d9gxzd7tpvrw"
},
{
"body": "On March 9, 2026, at 20:02 UTC, we identified an issue impacting Dedicated CPU plan Linodes, resulting in boot failures and resource allocation errors across multiple data centers. The problem was first reported by a customer who was unable to boot a newly provisioned Dedicated CPU Linode. We began investigating the issue on March 10, 2026, and escalated it internally on March 17, 2026, after receiving additional reports. By April 14, 2026, the incident had affected 35 Dedicated CPU plan hosts across seven data centers, including Amsterdam, London, Madrid, Atlanta, Chicago, Seattle, Washington, D.C., and Osaka. The issue was traced to a known software defect that caused validation failures during the boot process, leading to insufficient resource errors and preventing fallback allocations.\n\nSubject matter experts identified a missing configuration file as the root cause of the Dedicated Linode plan issues. To address this, we implemented a workaround script and began developing a long-term platform fix. We also introduced proactive alerting to detect similar issues in the future and updated our runbook with clear mitigation steps. Temporary monitoring will remain in place until the permanent fix is deployed. The permanent platform fix is scheduled for release by the end of May as part of our regular software update cycle.\u00a0\n\nWith the workaround script, runbook updates, and proactive alerting in place, we mitigated the broader customer impact by 14:42 UTC on April 16, 2026. If customers experience similar issues before the May platform release, we encourage them to contact Akamai Compute Support for assistance.\u00a0\n\nThis 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-16T19:32:42.082Z",
"resolved_inferred": false,
"started_at": "2026-04-14T18:33:05.378Z",
"state": "postmortem",
"title": "Service Issue - Dedicated CPU - Several Regions",
"updated_at": "2026-04-17T17:03:34.720Z",
"url": "https://stspg.io/1slk4sywyzwy"
},
{
"body": "We are currently deploying a fix for this issue in phases, which will take several months to complete. We will continue to share updates on our progress as the mitigation efforts move forward.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"started_at": "2025-12-03T15:15:27.643Z",
"state": "identified",
"title": "Service Issue - GPU and VPU Booting issues",
"updated_at": "2026-07-03T13:55:20.524Z",
"url": "https://stspg.io/cc42sd3y5lgb"
}
]
}