Historique des pannes de Linode

1. 24 août 2026 à 21:52 UTCinvestigating

   Notre équipe enquête sur un problème affectant le service de stockage d'objets aux États-Unis. Pendant ce temps, les utilisateurs peuvent rencontrer des erreurs 5xx intermittentes avec ce service.

2. 25 août 2026 à 00:31 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 25 août 2026 à 00:55 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 25 août 2026 à 01:11 UTCresolved

   Nous n'avons pas observé d'autres problèmes avec le service de stockage d'objets, et allons maintenant considérer cet incident résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 août 2026 à 17:23 UTCinvestigating

   Notre équipe enquête sur un nouveau problème de service touchant la mer (Seattle, WA). Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 21 août 2026 à 21:59 UTCresolved

   À l'heure actuelle, nous avons pu corriger le problème et le service a repris son fonctionnement normal.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 août 2026 à 20:13 UTCinvestigating

   Notre équipe étudie un problème touchant la connectivité dans notre centre de données IT-MIL (Milan). Pendant ce temps, les utilisateurs peuvent rencontrer des temps de connexion intermittents et des erreurs pour tous les services déployés dans ce centre de données. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 14 août 2026 à 21:18 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

3. 14 août 2026 à 21:30 UTCresolved

   Nous n'avons pas observé d'autres problèmes de connectivité dans notre centre de données IT-MIL (Milan) et allons maintenant considérer cet incident résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

4. 18 août 2026 à 19:02 UTCpostmortem

   Le 14 août 2026, à partir de 17:30 UTC, lors d'un événement dans notre centre de données IT-MIL \(Milan\), plusieurs alertes ont été déclenchées indiquant que plusieurs hôtes dans ce centre de données sont devenus inaccessibles. (en milliers de dollars) Akamai a immédiatement commencé à enquêter sur la question et à travailler pour restaurer les hôtes touchés. Au cours de la fenêtre d'impact, les clients auraient connu des temps de connexion intermittents et des erreurs dans tous les services déployés dans ce centre de données. (en milliers de dollars) Nous avons restauré les hôtes touchés et corrigé les problèmes de connectivité à 21h20 UTC le 14 août 2026. Nous enquêtons encore sur la cause de l'échec. (en milliers de dollars) Nous nous engageons à prévenir les incidents futurs et nous mènerons une enquête approfondie sur les raisons pour lesquelles les hôtes sont devenus inaccessibles, en mettant en œuvre des mesures pour améliorer la stabilité et la fiabilité. (en milliers de dollars) Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours, et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 août 2026 à 21:13 UTCinvestigating

   Notre équipe étudie un problème affectant la création de grappes Linode Kubernetes Engine Enterprise (LKE-E) dans le centre de données IAD2 - Washington. Il s'agit là d'une continuation de la question mentionnée précédemment. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 13 août 2026 à 23:02 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 13 août 2026 à 23:24 UTCresolved

   Cet incident a été résolu.

4. 18 août 2026 à 20:32 UTCpostmortem

   Entre 17h25 UTC et 22h50 UTC le 13 août 2026, les clients de Linode Kubernetes Engine Enterprise \(LKE-E\) essayant de déployer des instances Linode dédiées au G7 dans notre centre de données de Washington \(IAD2\), ont reçu 403 messages d'erreur de fourniture. Cette question n'a pas affecté la charge de travail et les instances actives. Notre enquête a révélé que même si la capacité matérielle totale de la DAI2 était suffisante, la demande de fourniture a déclenché un échec de vérification des droits en raison d'un seuil initial d'attribution de l'hôte. Akamai a résolu la question en augmentant la limite de Linode par hôte de 5 à 20 dans la SAI2. Les capacités de déploiement complètes ont été rétablies et stabilisées à 22h50 UTC. Afin d'éviter une reprise de l'activité, nous mettrons en place un système d'alerte spécifique pour les questions d'admissibilité et de capacité, directement lié aux manuels d'intervention pour une remise en état rapide. De plus, nous élaborons un tableau de bord centralisé de la capacité pour suivre de façon proactive la salle de tête régionale. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 août 2026 à 18:46 UTCinvestigating

   Notre équipe étudie un nouveau problème de service touchant l'API dans toutes les régions. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 13 août 2026 à 19:58 UTCmonitoring

   À partir de 19:30 UTC ont été en mesure de corriger le problème affectant l'API dans toutes les régions. Nous surveillerons cette situation pour nous assurer que le service demeure stable. Si vous rencontrez encore des problèmes et que vous ne pouvez pas ouvrir un ticket d'assistance, veuillez nous appeler au 855-454-6633 (+1-609-380-7100 Intl.), ou envoyer un courriel à [email protected].

3. 13 août 2026 à 19:59 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

4. 14 août 2026 à 00:26 UTCresolved

   Cet incident a été résolu.

5. 17 août 2026 à 17:38 UTCpostmortem

   Le 13 août 2026, vers 18h15 UTC, Akamai a observé une brève panne de service affectant [ api.linode.com ](http://api.linode.com). L'interruption totale du service a duré environ 3 minutes, terminant à 18h18 UTC. Suite à la restauration de la connectivité initiale, la latence de réponse API élevée a persisté jusqu'à 19:06 UTC, provoquant des temps de réponse plus lents et des retards intermittents pour les clients interagissant avec les services API. Pour remédier à l'impact de la performance, les équipes d'ingénierie d'Akamai ont identifié une divergence de configuration sur le nœud d'infrastructure secondaire qui l'a empêché d'absorber la totalité de la charge de trafic après la panne. Les ingénieurs ont effectué une migration contrôlée et ont déplacé le trafic de la demande vers l'hôte principal. À la suite de ce changement, la latence de l'API a rapidement diminué à des niveaux opérationnels normaux. L'état initial a été déclenché par un redémarrage inattendu de l'hôte physique du nœud de cache primaire. Bien que l'infrastructure redondante soit active, le nœud secondaire n'a pas été en mesure de traiter le trafic de rupture de manière transparente, ce qui a entraîné une dégradation des performances prolongée. Nos équipes d'ingénierie mènent une enquête de suivi sur les mécanismes de basculement afin d'optimiser les vitesses d'exécution et d'aligner les paramètres de configuration sur les nœuds redondants, assurant ainsi aux systèmes secondaires une gestion transparente du trafic dans les événements futurs. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 août 2026 à 16:16 UTCinvestigating

   Notre équipe enquête sur un problème touchant le Linode Kubernetes Engine (LKE). Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 13 août 2026 à 16:30 UTCmonitoring

   À l'heure actuelle, nous avons pu corriger les problèmes touchant le service LKE. Nous surveillerons cette situation pour nous assurer qu'elle demeure stable. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

3. 13 août 2026 à 17:54 UTCresolved

   Nous n'avons pas observé d'autres problèmes avec le service LKE, et nous allons maintenant considérer que cet incident a été résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

4. 17 août 2026 à 21:30 UTCpostmortem

   À partir d'environ 14h50 UTC le 13 août 2026, les clients qui ont tenté de fournir des grappes Linode Kubernetes Engine Enterprise \(LKE-E\) dans le centre de données IAD2 n'ont pas été en mesure de le faire. Nous avons constaté que le problème était dû à l'exclusion de deux composants de la DAI2 dans une mise à jour récente de la version logicielle qui a entraîné une inadéquation de l'API. Nous avons mis à jour les composants identifiés pour les synchroniser avec l'état prévu. Cela a atténué la question vers 16h00 UTC le 13 août 2026. Afin d'éviter que ce problème ne se produise à l'avenir, nous examinons les processus de mise à jour du logiciel LKE pour nous assurer que tous les composants inclus complètent les mises à jour de version avant d'être réintroduits au service lors des mises à jour du logiciel de la plate-forme. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 août 2026 à 15:46 UTCresolved

   Le 13 août 2026, entre 14 h et 16 h 30 UTC, nous avons observé des défaillances et des retards intermittents lors de la fourniture de nouvelles grappes LKE-E dans la région de Seattle (SEA1). La question touchant le service LKE-E à Seattle s'est corrigée à environ 16 h 30 UTC, et nous n'avons pas observé de récidive depuis. Nous enquêtons activement sur la cause. Nous continuerons de surveiller la stabilité du service. Si vous rencontrez des problèmes avec ce service, veuillez ouvrir un ticket d'assistance.

2. 21 août 2026 à 13:13 UTCpostmortem

   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. Akamai 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. By 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. We 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. 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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 août 2026 à 17:15 UTCinvestigating

   Notre équipe enquête sur un problème en amont touchant les déploiements Ubuntu. Cela peut affecter la capacité d'installer des mises à jour de paquet et de sécurité sur tous les systèmes Ubuntu.

2. 11 août 2026 à 23:35 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Les experts compétents sont engagés. Les mises à jour subséquentes concernant l'état des mesures d'atténuation seront affichées au fur et à mesure des progrès réalisés.

3. 12 août 2026 à 03:29 UTCidentified

   Nous avons identifié la cause du problème et une solution est en cours de mise en oeuvre. Nous fournirons une mise à jour dès que la solution sera en place.

4. 21 août 2026 à 18:40 UTCresolved

   Nous pouvons confirmer que la question a été atténuée à 6 h 30 UTC le 20 août 2026 et que le service a repris ses activités normales.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 juillet 2026 à 17:49 UTCinvestigating

   Notre équipe étudie la perte de paquets sur certains chemins des centres de données in-maa & in-bom-2 vers la région américaine. Pendant cette période, les utilisateurs peuvent rencontrer des temps de connexion et des erreurs avec des services traversant entre l'Inde et les États-Unis. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 31 juillet 2026 à 18:25 UTCidentified

   Notre équipe a identifié la cause de la perte de paquets pour nos centres de données américains. Nous travaillons avec notre fournisseur en amont pour résoudre ce problème et nous fournirons une mise à jour dès que la solution sera en place.

3. 4 août 2026 à 18:36 UTCidentified

   We are continuing to work with our upstream provider to resolve the packet loss affecting some paths between the in-maa and in-bom-2 data centers and the US region. We will share further updates as progress continues.

4. 5 août 2026 à 01:34 UTCresolved

   At this time the upstream provider has been able to correct the issue causing packet loss on some routes from the in-maa & in-bom-2 data centers into the US region and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. 5 août 2026 à 17:49 UTCpostmortem

   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’ 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. To 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.  The 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.  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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 juillet 2026 à 18:14 UTCinvestigating

   Notre équipe enquête sur un problème affectant le service de stockage de blocs dans plusieurs régions de centres de données. Cette question a des répercussions importantes sur les volumes d'assemblage et de stockage des blocs. Pendant ce temps, les utilisateurs peuvent éprouver des accrochages de volume/détachement, des chronométrages et des erreurs avec ce service. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 28 juillet 2026 à 19:27 UTCidentified

   Notre équipe a identifié le problème affectant le service de stockage de blocs dans nos centres de données. Nous travaillons rapidement à la mise en œuvre d'un correctif, et nous fournirons une mise à jour dès que la solution sera en place.

3. 28 juillet 2026 à 20:17 UTCidentified

   Nous aimerions mettre à jour qu'après une enquête supplémentaire, l'impact se manifesterait dans les emplois d'hôte retardés et parfois échoués, ce qui pourrait inclure de nombreuses actions différentes sur Linodes et non seulement l'impact de la fixation et de la détachage des volumes de stockage de blocs comme nous l'avons mentionné dans notre mise à jour initiale, nous avons mis à jour le titre pour refléter l'impact mis à jour. Nous travaillons rapidement à la mise en œuvre d'un correctif, et nous fournirons une mise à jour dès que la solution sera en place.

4. 28 juillet 2026 à 22:51 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 29 juillet 2026 à 12:27 UTCresolved

   Nous n'avons pas observé d'autres problèmes de dégradation de la performance des emplois hôtes, et nous allons maintenant considérer que cet incident est résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

6. 31 juillet 2026 à 18:57 UTCpostmortem

   Le 27 juillet 2026 à 3h30 UTC, Akamai a observé une augmentation des erreurs lors de la connexion à la base de données d'hébergement Linode, affectant principalement les pièces jointes de volume Block Storage. Cela s'est traduit par des échecs d'emploi d'hôte et une incidence limitée sur les clients, certains utilisateurs connaissant des messages d'erreur et des flux de travail interrompus. Des taux de temps d'attente élevés ont été notés dans les journaux pour certains emplacements des centres de données, ce qui coïncidait avec le déploiement progressif d'un nouveau drapeau de fonctionnalité. L'enquête initiale a révélé des chutes intermittentes de paquets du proxy de la base de données vers les hôtes clients pendant la poignée de main TLS. La théorie actuelle suggère qu'une limite de protection DDoS liée au paquet de chemin MTU trop gros messages ICMP a été atteinte. Lorsque le proxy a envoyé des paquets TCP avec une grande MTU, les messages ICMP attendus ont été supprimés par les routeurs de passerelle Dallas en raison du dépassement du taux autorisé configuré. Cela a causé des connexions TCP proxy de base de données vers timeout pour calculer les hôtes. Le problème a été déclenché par l'activation du nouveau drapeau de fonctionnalité, qui a changé le chemin de routage et a supprimé le serrage MTU avant que les paquets atteignent les passerelles. Pour atténuer le problème, Akamai a repoussé le récent changement de réseau dans les sites de calcul touchés, à partir de 20h50 UTC. À 22h57 UTC, le taux de redémarrage des services est revenu aux niveaux antérieurs à l'incident. Akamai prévoit également un changement pour augmenter le seuil autorisé pour les paquets trop gros messages ICMP. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juillet 2026 à 01:52 UTCinvestigating

   Notre équipe étudie actuellement un problème de connectivité touchant Linodes dans la région de Milan. Pendant ce temps, les linodes existantes dans cet endroit peuvent être inaccessibles. Veuillez noter que créer de nouveaux Linodes fonctionne normalement et reste inchangé.

2. 20 juillet 2026 à 02:56 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Nous fournirons la prochaine mise à jour au fur et à mesure que nous progresserons.

3. 20 juillet 2026 à 03:12 UTCinvestigating

   Notre équipe a identifié le problème affectant la connectivité dans notre centre de données de Milan (Italie). Nous travaillons rapidement à la mise en œuvre d'un correctif, et nous fournirons une mise à jour dès que la solution sera en place.

4. 20 juillet 2026 à 03:20 UTCmonitoring

   À l'heure actuelle, nous avons pu corriger les problèmes de connectivité dans notre centre de données de Milan (Italie). Nous surveillerons cette situation pour nous assurer qu'elle demeure stable. Si vous rencontrez encore des problèmes, veuillez ouvrir un ticket d'assistance.

5. 20 juillet 2026 à 04:10 UTCresolved

   Nous n'avons pas observé d'autres problèmes de connectivité dans notre centre de données de Milan (Italie) et allons maintenant considérer cet incident résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

6. 20 juillet 2026 à 05:45 UTCpostmortem

   À partir de 00h33 UTC le 20 juillet 2026, certains hôtes du centre de données de Milan, Italie, sont devenus indisponibles, ce qui a une incidence sur l'accès des clients à Linodes. L'enquête a révélé que ce problème s'était produit lors des mises à jour du firmware du routeur. Bien que nous suivions un processus de mise à niveau progressive pour prévenir la perturbation du service, une intersection inattendue d'activités de maintenance simultanée a entraîné une perte temporaire de connectivité réseau pour les hôtes touchés. Le service a été entièrement restauré par 02:16 UTC le 20 juillet 2026, et tous les systèmes fonctionnent maintenant comme prévu. À l'interne, nous réexaminons nos procédures de gestion du changement et de planification de la maintenance afin d'assurer une meilleure coordination et d'éviter des problèmes semblables à l'avenir. Nous nous excusons de l'impact et vous remercions de votre patience et de votre soutien continu. Nous nous engageons à apporter des améliorations continues pour améliorer nos systèmes et prévenir les récidives. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours, et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 juillet 2026 à 03:34 UTCinvestigating

   Notre équipe enquête sur un problème touchant le service de stockage d'objets. Pendant ce temps, les utilisateurs peuvent éprouver des temps de connexion et des erreurs avec ce service.

2. 18 juillet 2026 à 03:54 UTCidentified

   Notre équipe a identifié le problème touchant le service de stockage d'objets. Nous travaillons rapidement à la mise en œuvre d'un correctif, et nous fournirons une mise à jour dès que la solution sera en place.

3. 18 juillet 2026 à 04:36 UTCresolved

   Nous n'avons pas observé d'autres problèmes avec le service de stockage d'objets, et allons maintenant considérer cet incident résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

4. 21 juillet 2026 à 15:26 UTCpostmortem

   Le 18 juillet 2026, entre environ 00:30 UTC et 04:00 UTC, les utilisateurs auraient pu subir 5xx erreurs tout en essayant de créer un nouveau seau dans le stockage d'objets pour les paramètres suivants. * [us-ord-1.linodeobjects.com] (http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com] (http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com] (http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.com] (http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com] (http://fr-par-1.linodeobjects.com) Le problème a commencé lorsque l'infrastructure supportant Object Storage est entrée dans un état dégradé sur tous les nœuds. Cela a empêché le service de traiter les demandes, entraînant des défaillances lors des opérations de création de seau. Pour atténuer l'impact, nous avons appliqué un correctif au système moteur responsable de la création de seau. L'impact a été atténué à la suite de cette mesure. Nos experts en la matière enquêtent sur la cause fondamentale et prendront les mesures préventives appropriées. Nous nous excusons pour l'impact et apprécions votre patience et votre soutien continu. Nous apportons des changements de configuration et d'exploitation à nos systèmes afin d'éviter que cela ne se reproduise et nous restons déterminés à améliorer continuellement nos systèmes. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident, compte tenu de l'information disponible. Notre enquête est en cours, et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 01:24 UTCresolved

   Notre équipe a étudié un problème qui a affecté la connectivité dans notre centre de données US-MIA (Miami) entre 21h20 UTC et environ 23h28 UTC le 15 juillet 2026. Pendant cette fenêtre, les utilisateurs ont peut-être connu une dégradation des performances de réseau et une perte de paquets pour les services de calcul déployés dans cette région. Le problème a été résolu après la mise en oeuvre d'une solution. Nous continuons de travailler avec notre fournisseur de services tiers pour confirmer la cause fondamentale, car les premières preuves indiquent une panne de connexion croisée (fibre noire) sur leur infrastructure.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 juillet 2026 à 12:21 UTCinvestigating

   Notre équipe étudie un nouveau problème de service touchant l'API et l'ICL. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 14 juillet 2026 à 12:58 UTCidentified

   Notre équipe a identifié le problème affectant le gestionnaire Cloud et l'API. Nous travaillons rapidement à la mise en œuvre d'un correctif, et nous fournirons une mise à jour dès que la solution sera en place.

3. 14 juillet 2026 à 13:11 UTCmonitoring

   À l'heure actuelle, nous avons pu corriger le problème affectant le gestionnaire de cloud et l'API. Nous surveillerons cette situation pour nous assurer que le service demeure stable. Si vous rencontrez encore des problèmes et que vous ne pouvez pas ouvrir un ticket d'assistance, veuillez nous appeler au 855-454-6633 (+1-609-380-7100 Intl.), ou envoyer un courriel à [email protected].

4. 14 juillet 2026 à 18:36 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

5. 14 juillet 2026 à 19:26 UTCresolved

   Nous n'avons pas observé de problèmes supplémentaires avec le Cloud Manager, API ou CLI, et allons maintenant considérer cet incident résolu. Si vous continuez à éprouver des problèmes, veuillez nous contacter au 855-454-6633 (+1-609-380-7100 Intl.), ou envoyer un courriel à [email protected] pour de l'aide.

6. 16 juillet 2026 à 18:13 UTCpostmortem

   Le 14 juillet 2026, à 10h57 UTC, Akamai a identifié une augmentation de 502 erreurs et latence affectant les clients utilisant l'API Linode, CLI et Cloud Manager. Cette perturbation a eu un impact modéré sur le service, les clients signalant des taux d'erreur élevés. Notre première enquête a permis de retracer la question de la latence avec les services IAM, qui a été résolue, mais des erreurs élevées ont persisté. Une analyse plus approfondie effectuée par les experts compétents a permis de déterminer que l'incident avait été déclenché par une défaillance manuelle de l'équilibreur de charge primaire Cloud IAM de l'équilibreur de charge secondaire. Cette action a été déclenchée par un avertissement indiquant que l'équilibreur de charge secondaire agissait comme maître de conservation. Le processus manuel de démarrage et d'arrêt des services pour lancer le retour d'échec diffère du processus automatisé et conduit à une cascade de connexions GRPC statiques, entraînant une augmentation de la latence et des erreurs API. Le redémarrage des serveurs API a permis d'effacer les connexions et de rétablir les opérations normales. L'impact client a été atténué par environ 13:10 UTC le 14 juillet 2026. Pour prévenir la récurrence, Akamai enquête sur la raison pour laquelle le retour manuel a causé ce comportement. L'équipe envisage de mettre en place une commande de drainage pour nettoyer les connexions GRPC lors d'une panne et mettre en place des alertes pour détecter les connexions discontinues en vue d'une intervention proactive. Toutefois, l'accent reste immédiatement mis sur la compréhension de la cause fondamentale, l'alerte et l'automatisation étant prévues pour les phases ultérieures. Plusieurs clients ont confirmé la résolution de leurs déploiements. Akamai continuera à surveiller la santé du système et attendra des commentaires supplémentaires des clients avant de déclarer la récupération complète. Ce résumé donne un aperçu de notre compréhension actuelle de l'incident compte tenu de l'information disponible. Notre enquête est en cours et toute information ici peut être modifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 juillet 2026 à 18:29 UTCidentified

   Notre équipe a identifié un nouveau problème de service touchant les emplois d'accueil pour certains hôtes de toutes les régions. La connectivité Linode n'est pas affectée*, mais certains travaux au niveau de l'hôte, comme les sauvegardes ou les tentatives d'alimentation de vos services peuvent être retardés. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 13 juillet 2026 à 19:54 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 9 juillet 2026 à 16:57 UTCinvestigating

   Notre équipe étudie un nouveau problème de service affectant les connexions Cloud Manager. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 9 juillet 2026 à 17:24 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Nous fournirons une mise à jour dans les 30 prochaines minutes.

3. 9 juillet 2026 à 17:49 UTCmonitoring

   À l'heure actuelle, nous avons pu corriger le problème affectant les connexions Cloud Manager. Nous surveillerons cette situation pour nous assurer que le service demeure stable. Si vous rencontrez encore des problèmes et que vous ne pouvez pas ouvrir un ticket d'assistance, veuillez nous appeler au 855-454-6633 (+1-609-380-7100 Intl.), ou envoyer un courriel à [email protected].

4. 9 juillet 2026 à 18:21 UTCresolved

   Nous n'avons pas observé de problèmes supplémentaires avec les connexions Cloud Manager et allons maintenant considérer cet incident résolu. Si vous continuez à éprouver des problèmes, veuillez nous contacter au 855-454-6633 (+1-609-380-7100 Intl.), ou envoyer un courriel à [email protected] pour de l'aide.

5. 10 juillet 2026 à 12:30 UTCpostmortem

   Le 9 juillet 2026, à 15h43 UTC, les clients n'ont pas pu se connecter à [cloud.linode.com](http://cloud.linode.com) en utilisant leur nom d'utilisateur et leur mot de passe. Les clients recevaient un message d'erreur "mauvais mot de passe". L'enquête a révélé que la question était due à un certificat interne. Pour atténuer l'impact, nous avons corrigé la délivrance du certificat sur les serveurs touchés à 17h24 UTC le 9 juillet 2026. Après avoir surveillé nos systèmes pendant un certain temps, nous avons confirmé que la question était entièrement résolue. Akamai déploiera une solution permanente pour éviter que le problème ne se reproduise.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 6 juillet 2026 à 18:04 UTCinvestigating

   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. 7 juillet 2026 à 15:31 UTCresolved

   This incident has been resolved.

1. 1 juillet 2026 à 17:21 UTCidentified

   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. 1 juillet 2026 à 18:09 UTCmonitoring

   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. 1 juillet 2026 à 18:28 UTCresolved

   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.

1. 30 juin 2026 à 18:54 UTCinvestigating

   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. 30 juin 2026 à 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30 juin 2026 à 20:36 UTCidentified

   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. 30 juin 2026 à 21:36 UTCidentified

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

5. 30 juin 2026 à 22:10 UTCmonitoring

   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. 30 juin 2026 à 23:22 UTCresolved

   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. 2 juillet 2026 à 16:29 UTCpostmortem

   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.

1. 26 juin 2026 à 17:35 UTCinvestigating

   Notre équipe enquête sur un problème touchant les comptes rendus de Metrics de Base de données Managed. Le problème semble intermittent. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

2. 26 juin 2026 à 18:19 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Nous partagerons des mises à jour supplémentaires car nous avons plus d'informations.

3. 26 juin 2026 à 19:08 UTCinvestigating

   Nous continuons d'enquêter sur cette question. Nous fournirons d'autres mises à jour car nous avons plus d'informations.

4. 26 juin 2026 à 20:04 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

5. 26 juin 2026 à 21:13 UTCmonitoring

   Nous n'avons pas observé de récurrence de la question touchant les métriques d'impulsions nuageuses (ACLP Metrics) depuis plusieurs heures. Notre équipe continuera de surveiller de près le service pendant que nous enquêtons sur la cause sous-jacente. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

6. 30 juin 2026 à 00:02 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

7. 8 juillet 2026 à 12:26 UTCresolved

   Nous n'avons pas observé d'autres problèmes avec le service de Metrics Cloud Pulse (ACLP Metrics), et allons maintenant considérer cet incident résolu. Si vous continuez à rencontrer des problèmes, veuillez ouvrir un ticket d'assistance.

Traduit automatiquement depuis la mise à jour officielle de l'incident.