Linode Outage History

Started Jul 06, 2026, 06:04 PM UTC· resolved Jul 07, 2026, 03:31 PM UTC

1. investigating Jul 06, 2026, 06:04 PM UTC

   Our team is investigating an emerging service issue affecting Managed Databases across all regions. Customers may experience latency when provisioning new databases or deleting existing ones. There is no observed impact to the performance or availability of active, running databases at this time. We will provide updates as more information becomes available.

2. resolved Jul 07, 2026, 03:31 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 01, 2026, 05:21 PM UTC· resolved Jul 01, 2026, 06:28 PM UTC

1. identified Jul 01, 2026, 05:21 PM UTC

   Our team is investigating a service issue that affects the auto configuration of networking on Linodes by Network Helper to fail. During that time, some users may have Linodes provision but appear to have no connectivity. This also can impact Linodes created by the Linode Kubernetes Engine and impact autoscaling or provisioning of clusters. Customers can still manually configure networking via the LISH console to mitigate this issue. Please see our guide on manual network configuration on a Compute Instance. We will share additional updates as we have more information.

2. monitoring Jul 01, 2026, 06:09 PM UTC

   A fix has been implemented to resolve the automated network configuration issue on Linodes using Network Helper. We recommend rebooting your Linode to restore full network functionality. We are actively monitoring the results to ensure continued stability.

3. resolved Jul 01, 2026, 06:28 PM UTC

   We haven’t observed any additional issues with the Linode Automated Networking service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

Read the full incident report →

Started Jun 30, 2026, 06:54 PM UTC· resolved Jun 30, 2026, 11:22 PM UTC

1. investigating Jun 30, 2026, 06:54 PM UTC

   Our team is investigating an emerging issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. During this time, users may experience connection timeouts and errors with this service. We will share additional updates as we have more information.

2. investigating Jun 30, 2026, 07:55 PM UTC

   We are continuing to investigate this issue.

3. identified Jun 30, 2026, 08:36 PM UTC

   Our team has identified the issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

4. identified Jun 30, 2026, 09:36 PM UTC

   We are continuing to work on a fix for this issue.

5. monitoring Jun 30, 2026, 10:10 PM UTC

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

6. resolved Jun 30, 2026, 11:22 PM UTC

   We haven’t observed any additional issues with the Block Storage service in Singapore Expansion, SP (sg-sin-2), and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

7. postmortem Jul 02, 2026, 04:29 PM UTC

   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\). The 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. 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.

Read the full incident report →

Started Jun 26, 2026, 05:35 PM UTC· resolved Jul 08, 2026, 12:26 PM UTC

1. investigating Jun 26, 2026, 05:35 PM UTC

   Our team is investigating an issue affecting the Cloud Pulse Logs (ACLP Logs). The issue appears to be intermittent. We will share additional updates as we have more information.

2. investigating Jun 26, 2026, 06:19 PM UTC

   We are continuing to investigate this issue. We will share additional updates as we have more information.

3. investigating Jun 26, 2026, 07:08 PM UTC

   We are continuing to investigate this issue. We will provide further updates as we have more information.

4. investigating Jun 26, 2026, 08:04 PM UTC

   We are continuing to investigate this issue.

5. monitoring Jun 26, 2026, 09:13 PM UTC

   We have not observed a recurrence of the issue affecting the Cloud Pulse Metrics (ACLP Metrics) for several hours. Our team will continue to monitor the service closely while we investigate the underlying cause. If you continue to experience problems, please open a Support ticket for assistance.

6. monitoring Jun 30, 2026, 12:02 AM UTC

   We are continuing to monitor for any further issues.

7. resolved Jul 08, 2026, 12:26 PM UTC

   We haven’t 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 open a Support ticket for assistance.

Read the full incident report →

Started Jun 26, 2026, 05:14 PM UTC· resolved Jun 26, 2026, 07:33 PM UTC

1. investigating Jun 26, 2026, 05:14 PM UTC

   Our team is investigating an issue affecting connectivity in our US-IAD data center. During this time, users may experience intermittent connection timeouts and errors for services deployed in this data center. We will share additional updates as we have more information.

2. resolved Jun 26, 2026, 07:33 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 25, 2026, 02:33 PM UTC· resolved Jun 25, 2026, 06:42 PM UTC

1. investigating Jun 25, 2026, 02:33 PM UTC

   Our team is investigating an emerging service issue affecting migrations and resizes in all regions. At this time, Linode migrations and plan resizes may be delayed. We will share additional updates as we have more information.

2. monitoring Jun 25, 2026, 02:50 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 25, 2026, 06:42 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 24, 2026, 06:53 PM UTC· resolved Jun 25, 2026, 07:29 PM UTC

1. investigating Jun 24, 2026, 06:53 PM UTC

   Our team is investigating an emerging service issue that is causing intermittent boot failures on GPU Instances in all Regions. We will share additional updates as we have more information.

2. investigating Jun 24, 2026, 08:00 PM UTC

   We continue to investigate the issue that is causing intermittent boot failures on GPU Instances in all Regions. We will share additional updates as we have more information.

3. monitoring Jun 24, 2026, 09:12 PM UTC

   At 20:32 UTC on June 24th, 2026 we have been able to correct the issue that is causing intermittent boot failures on GPU Instances in all Regions. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

4. resolved Jun 25, 2026, 07:29 PM UTC

   We haven’t observed any additional boot failures on GPU Instances in all regions, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. postmortem Jun 26, 2026, 06:14 PM UTC

   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. During 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. In 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. In 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. 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.

Read the full incident report →

Started Jun 24, 2026, 08:12 AM UTC· resolved Jun 24, 2026, 12:35 PM UTC

1. resolved Jun 24, 2026, 04:27 PM UTC

   Between approximately 08:12 UTC and 12:35 UTC on June 24, 2026, attempting to create/autoscale Linodes using a Debian distribution may have failed due to a stale InRelease file in an upstream repository. We have mitigated the issue by updating our mirror endpoint to a healthy repository. If you continue to experience problems, please open a Support ticket for assistance.

2. postmortem Jun 24, 2026, 05:39 PM UTC

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

Read the full incident report →

Started Jun 16, 2026, 02:29 PM UTC· resolved Jun 16, 2026, 05:18 PM UTC

1. investigating Jun 16, 2026, 02:29 PM UTC

   Our team is investigating an emerging service issue affecting networking in US-MIA (Miami). We will share additional updates as we have more information.

2. resolved Jun 16, 2026, 05:18 PM UTC

   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.

3. postmortem Jun 22, 2026, 06:54 PM UTC

   On June 16, 2026 Akamai investigated an 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. 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. Actions were taken to mitigate the impact and restore intended routing paths. To prevent any further recurrence, we have temporarily suspended related configuration changes. Root 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. While 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. 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.

Read the full incident report →

Started Jun 16, 2026, 08:56 AM UTC· resolved Jun 16, 2026, 01:13 PM UTC

1. investigating Jun 16, 2026, 08:56 AM UTC

   Our team is investigating an issue affecting the Longview service. During this time, users may experience "waiting for data" in cloud manager and might not see the expected metrics. We will share additional updates as we have more information.

2. identified Jun 16, 2026, 09:46 AM UTC

   The issue has been identified and a fix is being implemented.

3. monitoring Jun 16, 2026, 09:48 AM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Jun 16, 2026, 01:13 PM UTC

   We haven’t observed any additional issues with the Longview service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. postmortem Jun 16, 2026, 04:48 PM UTC

   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:45 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.

Read the full incident report →

Started Jun 16, 2026, 03:44 AM UTC· resolved Jun 16, 2026, 06:06 AM UTC

1. identified Jun 16, 2026, 03:44 AM UTC

   Our team is investigating an emerging service issue affecting Linode Migrations in all regions. Migrations might be slow or pending for long time. We will share additional updates as we have more information.

2. monitoring Jun 16, 2026, 05:14 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Jun 16, 2026, 06:06 AM UTC

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

Read the full incident report →

Started Jun 05, 2026, 02:23 PM UTC· resolved Jun 05, 2026, 02:58 PM UTC

1. investigating Jun 05, 2026, 02:23 PM UTC

   We are currently investigating an emerging service issue affecting LKE Enterprise clusters across all regions. During this time, users may experience failures when deploying new clusters or upgrading existing ones. Our team is working to resolve this, and we will provide updates here as they become available.

2. resolved Jun 05, 2026, 02:58 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 03, 2026, 02:22 PM UTC· resolved Jun 04, 2026, 03:51 PM UTC

1. investigating Jun 03, 2026, 02:22 PM UTC

   Our team is investigating an upstream emerging service issue affecting our Support phone line due to problems with an upstream provider. We will share additional updates as we have more information. If you are having difficulty reaching us over the phone during this time, please reach us through a ticket.

2. investigating Jun 03, 2026, 06:33 PM UTC

   Our team is continuing to investigate an upstream service issue affecting our Support phone line. While stability of the service has improved, we have not yet identified the cause of the issue. We will share additional updates as we have more information. If you are having difficulty reaching us over the phone during this time, please open a Support ticket from the Cloud Manager.

3. resolved Jun 04, 2026, 03:51 PM UTC

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

Read the full incident report →

Started Jun 03, 2026, 08:58 AM UTC· resolved Jun 04, 2026, 09:11 AM UTC

1. investigating Jun 03, 2026, 08:58 AM UTC

   Our team is investigating an issue affecting the Block Storage service in our Newark, US data center. During this time, users may experience connection timeouts, latency and errors with this service. We will share additional updates as we have more information.

2. investigating Jun 03, 2026, 10:53 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jun 03, 2026, 11:25 AM UTC

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

4. investigating Jun 03, 2026, 12:55 PM UTC

   Our team is investigating an issue affecting the Block Storage service in our Newark, US data center. During this time, users may experience connection timeouts, latency and errors with this service. We will share additional updates as we have more information.

5. monitoring Jun 03, 2026, 03:44 PM UTC

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

6. resolved Jun 04, 2026, 09:11 AM UTC

   We haven’t observed any additional issues with the Block Storage service in Newark, US, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

7. postmortem Jun 04, 2026, 12:55 PM UTC

   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.

Read the full incident report →

Started May 22, 2026, 11:22 AM UTC· resolved May 26, 2026, 06:15 AM UTC

1. investigating May 22, 2026, 11:22 AM UTC

   We are investigating a service issue affecting traffic in our Paris data center. We will share additional updates as we have more information.

2. investigating May 22, 2026, 12:24 PM UTC

   We are continuing to investigate the issue

3. monitoring May 22, 2026, 01:14 PM UTC

   The issue subsided by 11:30 UTC on May 22, 2026, the impact was observed between 09:10 UTC to 11:30 UTC on May 22, 2026. We are actively monitoring this to ensure that the service remains stable . If you continue to experience problems, please open a Support ticket for assistance.

4. resolved May 26, 2026, 06:15 AM UTC

   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 open a Support ticket for assistance.

5. postmortem Jun 05, 2026, 11:01 AM UTC

   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.

Read the full incident report →

Started May 19, 2026, 07:48 PM UTC· resolved May 20, 2026, 12:27 AM UTC

1. identified May 19, 2026, 07:48 PM UTC

   Our team is investigating an emerging service issue affecting GPU provisioning in all regions. At this time deployment of RTX PRO 6000 Blackwell plans in unavailable. We will share additional updates as we have more information.

2. identified May 19, 2026, 09:06 PM UTC

   The issue with deployment of RTX PRO 6000 Blackwell plans appears to have started around 15:00 UTC on May 19, 2026. We are actively working to deploy an API hotfix that is expected to be rolled out within 1 hour. We apologize for the impact.

3. monitoring May 19, 2026, 09:58 PM UTC

   At this time we have been able to correct the issues affecting GPU provisioning in all regions as of 21:27 UTC. on May 19th. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

4. resolved May 20, 2026, 12:27 AM UTC

   We haven’t observed any additional issues with the GPU provisioning in all regions, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. postmortem May 25, 2026, 05:35 PM UTC

   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.

Read the full incident report →

Started May 16, 2026, 12:42 AM UTC· resolved May 16, 2026, 01:43 AM UTC

1. investigating May 16, 2026, 12:42 AM UTC

   Our team is investigating an emerging service issue affecting Linodes booting across all regions. We will share additional updates as we have more information.

2. investigating May 16, 2026, 01:06 AM UTC

   We are continuing to investigate this issue.

3. identified May 16, 2026, 01:27 AM UTC

   The issue has been identified and a fix has been implemented.

4. resolved May 16, 2026, 01:43 AM UTC

   This incident has been resolved.

5. postmortem May 20, 2026, 07:15 PM UTC

   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\) 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.

Read the full incident report →

Started May 15, 2026, 02:24 AM UTC· resolved May 15, 2026, 03:51 AM UTC

1. investigating May 15, 2026, 02:24 AM UTC

   We are currently investigating an issue causing delays to both cold and live migrations globally. A number of migrations are stuck, and additional migrations are queued and pending across all regions. Customer Impact: Cold and live migrations may be delayed or unresponsive. We recommend avoiding initiating new migrations until this is resolved. We are actively investigating the root cause and will provide an update shortly.

2. resolved May 15, 2026, 03:51 AM UTC

   We have identified the root cause of the migration delays affecting all regions. An unexpected reboot of several internal infrastructure components at approximately 22:10 UTC on May 14 resulted in incomplete reinitialization, causing the migration queue to stall.The affected components have now been reinitialized and migrations are processing normally. The pending queue has cleared and both cold and warm migrations as well as resize jobs are confirmed moving.

3. postmortem May 15, 2026, 06:32 AM UTC

   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.

Read the full incident report →

Started May 13, 2026, 09:02 PM UTC· resolved Jul 06, 2026, 02:42 PM UTC

1. investigating May 13, 2026, 09:02 PM UTC

   Akamai is aware of the recently disclosed “Fragnesia”[1] vulnerability, following the “DirtyFrag”[2] and “CopyFail”[3] disclosures. This vulnerability is very similar in nature and has a similar impact, exploit path, and mitigation approach. We have not observed any related malicious exploits targeting our infrastructure and are continuing to address the vulnerability across our product portfolio and internal systems. As with “CopyFail” and “DirtyFrag”, we are advising customers to consider most Linux distributions to be at-risk until patched. Since the “Fragnesia” vulnerability was disclosed prior to upstream patches having been made available, we are forced to wait for the different OS providers to create new releases or patches before we can integrate them into the versions we make available to customers. As this is a rapidly developing incident, we will provide further information regarding recommended actions, possible mitigations, and OS updates for all customers who may be affected. [1] https://github.com/v12-security/pocs/tree/main/fragnesia [2] https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md [3] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/

2. investigating May 15, 2026, 05:30 PM UTC

   We are responding to the publication of the most recent variation of the CopyFail[1] adjacent vulnerabilities “DirtyFrag” and “Fragnesia” with additional updates while we wait for upstream OS providers to release patches. Please see our detailed advisory[2] for more information on the current status, possible mitigation mechanisms, and our recommended actions. We will provide another update when more OS images have been updated and/or additional attack vectors are discovered. [1] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ [2] https://www.linode.com/docs/guides/dirty-frag-mitigation/

3. investigating Jun 05, 2026, 08:24 PM UTC

   We are responding to the publication of the most recent variation of the CopyFail[1] adjacent vulnerabilities “DirtyFrag” and “Fragnesia” with additional updates while we wait for upstream OS providers to release patches. Please see our detailed advisory[2] for more information on the current status, possible mitigation mechanisms, and our recommended actions. We will provide another update when more OS images have been updated and/or additional attack vectors are discovered. [1] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ [2] https://www.linode.com/docs/guides/dirty-frag-mitigation/

4. resolved Jul 06, 2026, 02:42 PM UTC

   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: https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ https://www.linode.com/docs/guides/dirty-frag-mitigation/ We 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 [email protected] for assistance.

Read the full incident report →

Started May 13, 2026, 09:42 AM UTC· resolved May 13, 2026, 02:37 PM UTC

1. investigating May 13, 2026, 09:42 AM UTC

   Our team is investigating an issue affecting connectivity in our NL-AMS data center. During this time, users may experience intermittent connection timeouts and errors for all services deployed in this data center. We will share additional updates as we have more information.

2. monitoring May 13, 2026, 10:44 AM UTC

   At this time we have been able to confirm that no customers should be impacted by the issues affecting connectivity in our NL-AMS data center. We will be monitoring this to ensure that it remains stable. If you are still experiencing issues, please open a Support ticket for assistance.

3. resolved May 13, 2026, 02:37 PM UTC

   We haven’t 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 open a Support ticket for assistance.

Read the full incident report →

Started May 12, 2026, 11:15 PM UTC· resolved May 12, 2026, 11:15 PM UTC

1. resolved May 15, 2026, 10:21 AM UTC

   Our team became aware of an issue affecting the Cloud Pulse Metrics for Managed Databases (ACLP Metrics) for two short periods on May 12 and May 14, 2026, and a fix has been applied. We haven’t observed any additional issues with the ACLP Metrics service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

2. postmortem May 18, 2026, 09:41 AM UTC

   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. * Window 1: May 12, 23:15 UTC – May 13, 00:11 UTC * Window 2: May 14, 06:47 UTC – 07:33 UTC During 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. Remark: 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’ underlying Managed Databases were never impacted. The disruption was caused by a cascading failure initiated by a brief network routing issue. During 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. This "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. To 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. 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.

Read the full incident report →

Started May 12, 2026, 05:12 PM UTC· resolved May 13, 2026, 01:02 AM UTC

1. investigating May 12, 2026, 05:12 PM UTC

   Our team is investigating an issue affecting connectivity in our AP-West (Mumbai) and IN-MAA (Chennai) data centers. During this time, users may experience intermittent connection timeouts and errors for all services deployed in this data center. We will share additional updates as we have more information.

2. investigating May 12, 2026, 05:54 PM UTC

   We are continuing to investigate the issue with our service provider. We will share additional updates as we have more information.

3. identified May 12, 2026, 07:52 PM UTC

   Our third-party service provider has identified the issue affecting connectivity in our AP-West (Mumbai) and IN-MAA (Chennai) data centers, and a fix is being implemented. We will provide an update as soon as the solution is in place.

4. identified May 12, 2026, 10:47 PM UTC

   We are continuing to work with our service provider on a fix for this issue.

5. resolved May 13, 2026, 01:02 AM UTC

   This incident has been resolved. While we continue to monitor the upstream provider's progress on their underlying connectivity issue, our services are now stable on alternative paths.

6. postmortem May 14, 2026, 03:10 PM UTC

   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. The 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. Service 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. Akamai will continue working with the involved Internet Service Providers to address the underlying congestion and help prevent recurrence. 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.

Read the full incident report →

Started May 08, 2026, 01:40 PM UTC· resolved Jul 06, 2026, 02:41 PM UTC

1. investigating May 08, 2026, 01:40 PM UTC

   Akamai is aware of the recently disclosed “DirtyFrag”[1] vulnerability that followed the “CopyFail”[2] disclosure. This vulnerability is very similar in nature and has a similar impact, exploit path, and mitigation approach. We have not observed any related malicious exploits targeting our infrastructure and are continuing to address the vulnerability across our product portfolio and internal systems. As with “CopyFail”, we are advising customers to consider most Linux distributions to be at-risk until patched. Since the “DirtyFrag” vulnerability was disclosed prior to upstream patches having been made available, we are forced to wait for the different OS providers to create new releases or patches before we can integrate them into the versions we make available to customers. As this is a rapidly developing incident, we will provide further information regarding recommended actions, possible mitigations, and OS updates for all customers who may be affected. [1] https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md [2] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/

2. investigating May 09, 2026, 02:40 PM UTC

   We have updated our latest Linode kernel to version 7.0.5, which contains the upstream fix from kernel.org for the DirtyFrag vulnerabilities as well as the previous fixes for the recent CopyFail vulnerability. This kernel is available in Cloud Manager and we recommend customers using the Linode-compiled kernel update their configurations to this kernel. We are in parallel tracking the upstream Linux distributions and will provide another update when fixed versions have been released. Note: Due to metadata caching, the Cloud Manager interface for some users may still show the “latest” kernel as 7.0.3; selecting “latest” will, however, get you version 7.0.5 as of this writing.

3. investigating May 15, 2026, 05:28 PM UTC

   We are responding to the publication of the most recent variation of the CopyFail[1] adjacent vulnerabilities “DirtyFrag” and “Fragnesia” with additional updates while we wait for upstream OS providers to release patches. Please see our detailed advisory[2] for more information on the current status, possible mitigation mechanisms, and our recommended actions. We will provide another update when more OS images have been updated and/or additional attack vectors are discovered. [1] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ [2] https://www.linode.com/docs/guides/dirty-frag-mitigation/

4. investigating Jun 05, 2026, 08:23 PM UTC

   We are responding to the publication of the most recent variation of the CopyFail[1] adjacent vulnerabilities “DirtyFrag” and “Fragnesia” with additional updates while we wait for upstream OS providers to release patches. Please see our detailed advisory[2] for more information on the current status, possible mitigation mechanisms, and our recommended actions. We will provide another update when more OS images have been updated and/or additional attack vectors are discovered. [1] https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ [2] https://www.linode.com/docs/guides/dirty-frag-mitigation/

5. resolved Jul 06, 2026, 02:41 PM UTC

   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: https://www.linode.com/docs/guides/cve-2026-31431-copy-fail-mitigation/ https://www.linode.com/docs/guides/dirty-frag-mitigation/ We 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 [email protected] for assistance.

Read the full incident report →

Started May 01, 2026, 05:51 PM UTC· resolved May 05, 2026, 10:19 PM UTC

1. investigating May 01, 2026, 05:51 PM UTC

   Akamai is aware of the recently disclosed “Copy Fail” vulnerability (CVE-2026-31431). We are assessing the issue and are working to address it across our product portfolio and internal systems. While we have not observed any related malicious exploits targeting our infrastructure, Akamai continuously works to reduce risks and enhance our security posture. We are taking both immediate and longer-term steps to mitigate potential impacts and help ensure the continued confidence of our customers. Per our Shared Security Model[1], customers are responsible for making sure their service’s installed applications and code are securely configured and patched. Given the nature of this vulnerability, it should be assumed that all virtual machines running Linux are at-risk until patched. We will be publishing more details as patches are incorporated into the base images that we supply, but we strongly recommend customers deploy mitigations on all instances. Furthermore, the nature of the vulnerability suggests that container escapes are possible, so customers allowing untrusted workloads to execute in their containers may need to take additional steps to secure their containerized workloads. We will provide further information regarding our posture and recommended actions for Akamai Compute customers who may be affected. [1] https://www.akamai.com/legal/security

2. investigating May 01, 2026, 05:52 PM UTC

   We are continuing to investigate this issue.

3. resolved May 05, 2026, 10:19 PM UTC

   We have completed our investigation and response to the “Copy Fail” 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/ We 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 [email protected] for assistance.

Read the full incident report →

Started Apr 29, 2026, 09:22 AM UTC· resolved Apr 29, 2026, 07:19 PM UTC

1. investigating Apr 29, 2026, 09:22 AM UTC

   We are aware that some customers have been experiencing 403 (InvalidAccessKeyId) errors when attempting to access object storage, beginning yesterday evening. We will share additional updates as we have more information.

2. investigating Apr 29, 2026, 10:30 AM UTC

   Our team is investigating an issue affecting the Object Storage service. During this time, users may experience connection timeouts and errors with this service.

3. investigating Apr 29, 2026, 11:42 AM UTC

   We are continuing to investigate this issue.

4. investigating Apr 29, 2026, 12:41 PM UTC

   We are continuing to investigate this issue.

5. resolved Apr 29, 2026, 07:19 PM UTC

   We haven’t observed any additional issues with the Object Storage service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

6. postmortem Apr 30, 2026, 01:05 PM UTC

   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. Our 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. To resolve the issue, we have restarted the reconciler and key operations were processed for customers. To 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. 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.

Read the full incident report →