Historique des pannes de Launchdarkly

1. 26 octobre 2026 à 20:52 UTCresolved

   Un point d'inflexion à l'échelle dans notre entrepôt en temps réel a entraîné un retard pour l'ingestion d'un événement. L'équipe d'ingénierie a corrigé le problème et tous les événements devraient être rattrapés. Certains clients ont peut-être vu des retards dans les expériences et dans le traitement des rejets surveillés. Ceci est maintenant résolu et l'équipe suivra attentivement.

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

1. 15 octobre 2026 à 15:47 UTCresolved

   Entre 15:11 et 15:32 UTC aujourd'hui, nous avons observé des erreurs 5xx élevées affectant les demandes à travers nos services. Environ 0,7 % des demandes ont échoué au cours de cette période (99,3 % ont réussi). Cet incident a été résolu.

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

1. 3 octobre 2026 à 07:29 UTCidentified

   Certains changements automatiques dans LaunchDarkly sont appliqués plus tard que prévu. Cela affecte les transitions en étape pour les déploiements surveillés et progressifs, la progression de la phase du pipeline et les réaffectations de trafic de banditisme multi-armes. Les retards ont commencé vers 16 h 15 HNE le 2 octobre 2026. Les déploiements et les expériences en cours restent à leur stade actuel et la répartition du trafic; rien n'a été avancé, retourné ou arrêté incorrectement. Aucune donnée n'est perdue. Les changements retardés restent en attente et entreront en vigueur lorsque le traitement aura pris fin.

2. 3 octobre 2026 à 08:51 UTCmonitoring

   L'arriéré de modifications retardées a été entièrement traité à compter du 3 octobre à 13 h 45. Tous les changements qui ont été retardés pendant l'incident ont été appliqués. Aucune donnée n'a été perdue. Nous continuons de surveiller.

3. 3 octobre 2026 à 09:06 UTCresolved

   Cet incident a été résolu.

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

1. 2 octobre 2026 à 14:10 UTCidentified

   Nous enquêtons sur les taux d'erreur élevés affectant l'application Web LaunchDarkly et l'API. Certaines demandes peuvent échouer ou se terminer par intermittence, y compris la gestion de rôles sur mesure. Nous partagerons une mise à jour en apprenant davantage.

2. 2 octobre 2026 à 17:29 UTCidentified

   Identifié. Nous avons identifié la cause des taux d'erreur élevés et travaillons sur une correction. Les clients peuvent encore être incapables de lister, de rechercher ou d'attribuer des rôles personnalisés; les rôles existants continuent d'être appliqués. La plupart des autres fonctions fonctionnent normalement, bien que certaines demandes puissent échouer par intermittence. Nous partagerons une autre mise à jour à mesure que la récupération progresse.

3. 3 octobre 2026 à 01:26 UTCmonitoring

   Contrôle. Nous avons appliqué une correction et les taux d'erreur sont revenus à la normale, y compris la liste de rôles personnalisée, la recherche et l'affectation. Nous continuons à surveiller pendant que nous terminons les travaux de rétablissement.

4. 3 octobre 2026 à 09:05 UTCresolved

   Cet incident a été résolu.

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

1. 26 août 2026 à 19:45 UTCmonitoring

   Les demandes de streaming côté serveur ont connu des taux d'erreur élevés entre environ 12h00 et 12h12 PDT, et certains SDK établissant de nouvelles connexions de streaming ont pu être incapables de se connecter. Les taux d'erreur de la demande de sondage sont demeurés inférieurs à 1% tout au long de l'incident. Aucune donnée client n'a été perdue ou compromise. Nous nous excusons pour la perturbation.

2. 26 août 2026 à 20:00 UTCresolved

   Cet incident a été résolu. Entre 12h et 12h12 PDT le 26 août, les SDK côté serveur établissant de nouvelles connexions en streaming ont connu des taux d'erreur élevés. Les connexions actuelles de diffusion en continu n'ont pas été touchées, et les demandes de vote ont continué d'être servies avec des taux d'erreur inférieurs à 1%. Certaines demandes adressées à l'application Web LaunchDarkly ont également fait l'objet d'erreurs élevées entre 11h29 et 12h03. Le problème a été causé par un changement de configuration interne, qui a été repris. Tous les systèmes ont récupéré et fonctionnent normalement. Aucune donnée client n'a été perdue ou compromise.

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

1. 24 août 2026 à 12:20 UTCidentified

   Les courriels envoyés par LaunchDarkly — y compris la vérification de l'inscription, la réinitialisation du mot de passe, l'invitation des coéquipiers et les courriels de notification de flux de travail — ne sont actuellement pas livrés en raison d'un problème d'authentification avec un fournisseur de messagerie en amont. Nous avons identifié la cause et nous travaillons à rétablir la livraison. La livraison des drapeaux, les SDK et l'application LaunchDarkly elle-même ne sont pas affectées. Si vous essayez de compléter l'inscription ou de réinitialiser un mot de passe, ces courriels n'arriveront pas avant que cela soit résolu. Une fois la livraison rétablie, nous renvoyons les courriels de vérification et de réinitialisation du mot de passe touchés. Prochaine mise à jour dans les 2 heures.

2. 24 août 2026 à 13:36 UTCresolved

   La livraison par courriel a été rétablie à partir de 2:32 PM UTC. La vérification de l'inscription, la réinitialisation du mot de passe, l'invitation du coéquipier et les courriels de notification sont envoyés à nouveau normalement. Nous renouvelons la vérification de l'inscription et réinitialisons les courriels qui n'ont pas été livrés pendant la fenêtre de l'incident (22 août, 11:48 PM CDT jusqu'à aujourd'hui). Si vous avez tenté de vous inscrire ou de réinitialiser un mot de passe pendant cette période et que vous n'avez pas reçu de courriel dans les prochaines heures, veuillez réessayer l'action ou le support de contact. Nous continuons à surveiller de près la livraison des courriels et publierons une mise à jour finale une fois que nous aurons confirmé une reprise soutenue.

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

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

   Nous vivons une dégradation de service qui peut entraîner des mises à jour de drapeau via l'API de sondage à retarder.

2. 17 août 2026 à 15:29 UTCmonitoring

   Nous avons identifié la cause profonde, notre fournisseur de CDN avait un problème à leur fin qui est corrigé maintenant. Surveillance pendant un certain temps pour s'assurer que les choses se stabilisent.

3. 17 août 2026 à 16:03 UTCresolved

   Cet incident a été résolu.

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

1. 14 août 2026 à 14:47 UTCinvestigating

   Les mises à jour du drapeau sont actuellement retardées dans la région de l'est-1. Nous enquêtons sur la question.

2. 14 août 2026 à 16:05 UTCmonitoring

   Nous avons étudié les taux d'erreur élevés signalés pour la livraison mobile du drapeau SDK à US East. Nous avons confirmé que la livraison du drapeau n'a pas été touchée. Aucune action client n'est requise et nous surveillons la situation.

3. 14 août 2026 à 16:47 UTCresolved

   La question est considérée comme résolue. Nous voyons de meilleurs latences et nos systèmes se sont rétablis.

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

1. 7 août 2026 à 19:29 UTCinvestigating

   Nous enquêtons sur des erreurs HTTP 500 élevées affectant certains SDK côté serveur les connexions en streaming dans notre environnement commercial américain. Demandes touchées peut ne pas établir ou peut perdre par intermittence leur connexion Lancement noir.

2. 7 août 2026 à 19:56 UTCinvestigating

   We released several mitigations and we're noticing that error rates are dropping. We'll continue to monitor the situation.

3. 7 août 2026 à 20:12 UTCinvestigating

   We are continuing to investigate this issue.

4. 7 août 2026 à 20:15 UTCresolved

   SDKs restored to operational

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

1. 31 juillet 2026 à 17:44 UTCinvestigating

   Tous les clients ont des traces d'observation manquantes à partir du 30 juillet à 17h16 PT. Nous enquêtons et fournirons des mises à jour dès qu'elles seront disponibles. Les données de trace ne sont pas perdues et nous travaillons pour les récupérer.

2. 31 juillet 2026 à 17:59 UTCidentified

   Les clients sont absents Observabilité Traces ingérés du 30 juillet 17h16 jusqu'au 31 juillet 10h59 PT. Nous avons identifié le problème et nous poursuivons nos travaux pour récupérer les données de Traces manquantes.

3. 31 juillet 2026 à 21:58 UTCmonitoring

   Le problème des traces d'observation a été identifié et une correction a été mise en œuvre. Nous avons récupéré la plupart des données de traces manquantes du 30 juillet 17h16 au 31 juillet 10h59 PT. Nous résoudrons l'incident une fois que nous aurons complètement terminé la récupération des données (prévue pour 17h).

4. 31 juillet 2026 à 22:54 UTCresolved

   Le problème des traces d'observation a été résolu. Les données manquantes ont été récupérées.

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

1. 28 juillet 2026 à 19:24 UTCidentified

   Les clients connaissent des rejouements de session retardés et ingérés d'erreur à partir de 11:03am PT. Nous avons identifié la question et nous poursuivons nos travaux pour la résoudre. La perte de données n'est pas prévue.

2. 28 juillet 2026 à 19:41 UTCmonitoring

   Le problème avec le replay de session et l'ingestion d'erreur a été identifié et une correction a été mise en œuvre. Nous nous attendons à rattraper le retard accumulé dans l'ingestion de données en ~15 minutes. Aucune donnée n'a été perdue.

3. 28 juillet 2026 à 20:04 UTCresolved

   Le problème avec le replay de session et l'ingestion d'erreur a été résolu. Nous avons rattrapé toutes les données accumulées à partir de 13h01 PT.

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

1. 26 juillet 2026 à 19:09 UTCresolved

   Entre 11:32 et 11:48 PT, les clients ont connu une latence accrue et des taux d'erreur élevés sur les paramètres de l'API. Les taux de latence et d'erreur sont revenus à la normale, et l'incident a été résolu.

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

1. 10 juillet 2026 à 17:10 UTCinvestigating

   L'application Web LaunchDarkly (app.launchdarkly.com) n'était pas disponible et est en cours de récupération. Le réseau de livraison des drapeaux a également été touché, ce qui a entraîné un taux de défaillance élevé avec la récupération des valeurs des drapeaux. Les clients utilisant des SDK côté client ou côté serveur devraient continuer à voir les dernières valeurs d'affichage connues si un cache local existe, ou revenir aux valeurs en code. Les clients utilisant notre Relay Proxy devraient continuer à voir les dernières valeurs connues de drapeau si un cache local existe. Les clients utilisant nos SDK Edge devraient continuer à voir les dernières valeurs connues du drapeau. Il se peut que certaines pertes de données aient eu lieu.

2. 10 juillet 2026 à 17:12 UTCidentified

   Nous avons identifié la cause fondamentale et mettons en œuvre une solution.

3. 10 juillet 2026 à 17:40 UTCidentified

   La disponibilité des applications web s'est rétablie. La livraison des drapeaux et l'ingestion des événements continuent d'être touchées et se rétablissent activement. Notre équipe d'ingénieurs continue de travailler à l'assainissement.

4. 10 juillet 2026 à 17:54 UTCmonitoring

   L'impact des services de production a été rétabli. Cependant, les clients pourraient avoir besoin de redémarrer leurs applications pour se connecter pleinement aux services de LaunchDarkly. Notre équipe d'ingénierie travaille sur des conseils qui peuvent être fournis aux clients.

5. 10 juillet 2026 à 18:19 UTCresolved

   Toute la disponibilité du service a été entièrement restaurée. Les clients utilisant des SDK côté serveur pourraient avoir besoin de redémarrer leurs applications pour réactiver la connexion des SDK vers LaunchDarkly. Les clients utilisant le Relay Proxy peuvent également avoir besoin de redémarrer leur Relay Proxy; dans ce cas, le Relay Proxy devrait être redémarré avant de redémarrer leurs applications qui se connectent à lui. Pour déterminer si une application doit être redémarrée, les clients peuvent regarder leurs journaux d'application. Les SDK touchés émettront (selon la langue) des journaux contenant l'un des documents suivants : « abandon définitif », « clé SDK invalide », « non autorisée » ou « non autorisée » ou « 401 ». Les services qui ont émis des journaux tels que ceux-ci avant 9:13 AM PT peuvent être incapables de recevoir des mises à jour de drapeau et seront incapables d'envoyer des événements à LaunchDarkly jusqu'à ce qu'ils soient redémarrés.

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

1. 10 juillet 2026 à 16:16 UTCinvestigating

   Nous enquêtons actuellement sur cette question

2. 10 juillet 2026 à 16:17 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 10 juillet 2026 à 16:26 UTCidentified

   Le problème a été identifié et un correctif a été mis en œuvre

4. 10 juillet 2026 à 17:43 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

5. 10 juillet 2026 à 17:48 UTCresolved

   LaunchDarkly UI a récupéré. Nous continuerons à surveiller la livraison des drapeaux et l'ingestion des événements ici: https://status.launchdarkly.com/incidents/chywwz01ptb0.

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

1. 10 juillet 2026 à 19:21 UTCinvestigating

   Nous enquêtons sur la poursuite de l'impact sur le SDK mobile et serveur des clients causé par l'incident précédent (https://status.launchdarkly.com/incidents/chywwz01ptb0). Si les clients reçoivent SDK ou Relay Proxy 401s, veuillez rétablir les connexions.

2. 10 juillet 2026 à 20:18 UTCmonitoring

   Nos services Flag Delivery se sont rétablis et nous observons une augmentation du trafic client rétablissant avec succès les connexions à nos services de streaming. Les clients qui continuent à rencontrer 401 erreurs de connexion dans leurs instances SDK ou Relay Proxy sont invités à redémarrer leurs applications et/ou Relay Proxy.

3. 10 juillet 2026 à 23:32 UTCmonitoring

   Les clients continuent de rétablir avec succès les connexions à nos services de streaming. Nous vous recommandons d'examiner les journaux de vos demandes pour la fenêtre des incidents. Les SDK touchés émettent des messages, variant selon la langue, qui contiennent l'un des éléments suivants : « abandon définitif », « clé SDK invalide », « non autorisée », « non autorisée » ou « 401 ». Tout service qui a enregistré ces messages peut ne pas être en mesure de recevoir des mises à jour du drapeau ou d'envoyer des données d'événement jusqu'à ce qu'il soit redémarré. Voici les mesures recommandées pour chaque application touchée : - Si vous utilisez des SDK côté serveur, veuillez redémarrer l'application pour rétablir sa connexion à LaunchDarkly. - Si le rétablissement de la connexion au SDK côté serveur ne fonctionne pas, veuillez créer et utiliser une seconde clé SDK. - Si vous utilisez le Relay Proxy, veuillez redémarrer le Relay Proxy pour rétablir les connexions. Il ne devrait pas être nécessaire de redémarrer les applications derrière elle. - Les SDK côté client se reconnectent automatiquement au redémarrage. - Si cela ne résout pas le problème d'une application touchée (p. ex., vous voyez toujours les messages de journal d'en haut), veuillez enregistrer un ticket d'assistance et nous ferons un suivi avec vous directement pour aider à l'assainissement.

4. 11 juillet 2026 à 02:00 UTCmonitoring

   Nous continuons de surveiller tout autre problème, voir notre mise à jour précédente pour les étapes de récupération.

5. 13 juillet 2026 à 18:08 UTCmonitoring

   Tous les services LaunchDarkly sont opérationnels, bien que certains clients doivent prendre des mesures pour restaurer leurs connexions à notre réseau de livraison Flag. Les clients continuent de rétablir les connexions avec succès en complétant les lignes directrices d'action ci-dessous et nous continuons à soutenir les clients travaillant à travers l'impact résiduel. Les cas SDK et Relay Proxy qui ont tenté d'établir une connexion avec LaunchDarkly le 10 juillet entre 09:11 et 11:42 AM PT ont été touchés de façon intermittente. Cela comprend les situations où l'application hôte a été redémarrée ou redéployée pendant cette période. Les cas SDK et Relay Proxy qui n'ont pas tenté d'établir de connexion pendant cette période n'ont pas été touchés. Nous vous recommandons d'examiner les journaux de vos demandes pour la fenêtre des incidents. Les SDK touchés émettent des messages, variant selon la langue, qui contiennent l'un des éléments suivants : « abandon définitif », « clé SDK invalide », « non autorisée », « non autorisée » ou « 401 ». Tout service qui a enregistré ces messages peut ne pas être en mesure de recevoir des mises à jour du drapeau ou d'envoyer des données d'événement jusqu'à ce qu'il soit redémarré. Voici les mesures recommandées pour chaque application touchée : - Si vous utilisez le Relay Proxy, veuillez redémarrer le Relay Proxy pour rétablir les connexions. Il ne devrait pas être nécessaire de redémarrer les applications derrière elle, mais nous recommandons d'examiner vos journaux d'applications pour confirmer si redémarrer vos applications est nécessaire. - Si vous utilisez des SDK côté serveur sans le Relay Proxy, veuillez redémarrer l'application pour rétablir sa connexion à LaunchDarkly. - Les SDK côté client et mobile se reconnecteront automatiquement lorsque leurs applications tenteront de se reconnecter à LaunchDarkly dans des circonstances normales, par exemple lorsque l'application charge ou que l'appareil reprend la connectivité réseau. - Si cela ne résout pas le problème d'une application touchée (p. ex., vous voyez toujours les messages de journal d'en haut), veuillez enregistrer un ticket d'assistance et nous ferons un suivi avec vous directement pour aider à l'assainissement.

6. 29 juillet 2026 à 18:15 UTCresolved

   Cet incident a été résolu.

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

1. 8 juillet 2026 à 18:03 UTCinvestigating

   Nous enquêtons actuellement sur un problème où les expériences utilisant l'analyse fréquentiste ne peuvent pas être sauvegardées ou lancées.

2. 8 juillet 2026 à 18:12 UTCidentified

   Nous avons identifié le problème et nous travaillons à la publication d'un correctif.

3. 8 juillet 2026 à 18:51 UTCmonitoring

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

4. 8 juillet 2026 à 19:41 UTCresolved

   Cet incident a été résolu.

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

1. 7 juillet 2026 à 15:10 UTCresolved

   L'ingestion d'événement fonctionne normalement. Résultats d'expérimentation, Guarded Les déploiements et les diagrammes de données en cours de production ont été retardés d'environ 5 min entre 7h13 et 7h53. Aucune donnée n'a été perdue. Nous nous excusons pour tout désagrément.

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

1. 6 juillet 2026 à 20:52 UTCinvestigating

   À 13 h 21 Pacifique Temps, nous avons connu un volume élevé d'alertes d'erreurs affectant la capacité des utilisateurs d'interagir avec l'application LaunchDarkly, y compris la connexion et la réactivité de l'interface utilisateur/API. Nous avons rapidement identifié la cause profonde de la livraison du drapeau. Nous nous attendons à ce que les erreurs diminuent maintenant.

2. 6 juillet 2026 à 21:08 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 juillet 2026 à 21:09 UTCmonitoring

   Nous avons déployé une correction et les taux d'erreur sont de retour à la normale

4. 6 juillet 2026 à 21:21 UTCresolved

   Tous les taux d'erreur ont été normalisés.

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

1. 6 juillet 2026 à 14:33 UTCinvestigating

   Certains clients ne reçoivent pas de courriels de vérification de compte. Notre équipe travaille activement à atténuer ce problème.

2. 6 juillet 2026 à 14:45 UTCmonitoring

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

3. 6 juillet 2026 à 15:52 UTCresolved

   Cet incident a été résolu.

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

1. 3 juillet 2026 à 14:29 UTCinvestigating

   Nous étudions des taux d'erreur élevés sur nos paramètres d'ingestion de données d'événements affectant les clients de production, entre environ 7h00 et 7h15. Au cours de cette fenêtre, une partie du drapeau des caractéristiques, de l'expérimentation et des données sur l'IA/agent peut avoir été rejetée ou retardée. La livraison et l'évaluation du drapeau ne sont pas affectées. Les SDK continuent de servir les drapeaux normalement. L'ingestion d'observabilité n'est pas affectée.

2. 3 juillet 2026 à 15:13 UTCmonitoring

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

3. 3 juillet 2026 à 16:06 UTCresolved

   Cet incident a été résolu.

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