Historique des pannes de Launchdarkly

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.

1. 17 juin 2026 à 19:43 UTCidentified

   LaunchDarkly web application and flag delivery unaffected, but documentation and LaunchDarkly.com are unavailable for some users. A fix is on the way.

2. 17 juin 2026 à 19:59 UTCmonitoring

   A fix has been implemented and monitoring the results.

3. 17 juin 2026 à 23:56 UTCmonitoring

   Incident seems to be resolved for the majority of users, however, we are continuing to see some issues for in the San Jose and Los Angeles region. We're working to remediate for these regions.

4. 18 juin 2026 à 01:23 UTCmonitoring

   We've identified the source of the problem for areas that were still seeing issues with the LaunchDarkly.com and docs and have a solution in place. We are now monitoring to ensure everything is resolved.

5. 18 juin 2026 à 01:30 UTCresolved

   We're now seeing restored access in the affected regions.

1. 15 juin 2026 à 17:26 UTCidentified

   Some customers are experiencing delayed Observability data ingest for OpenTelemetry data. We have identified the issue and are continuing our work to resolve it. Observability signals (errors / logs / traces / OTel metrics) are currently delayed by ~6 minutes on average. Data ingest delays began at 10:02am and are improving as of 10:16am PT.

2. 15 juin 2026 à 17:33 UTCmonitoring

   The issue with Observability data ingest for OpenTelemetry data has been identified and a fix has been implemented. We are continuing to monitor the performance of impacted services. We will continue to update this page until it is resolved. Observability signals (errors / logs / traces / OTel metrics) are currently delayed by <1 minutes on average.

3. 15 juin 2026 à 17:38 UTCresolved

   The issue with Observability data ingest for OpenTelemetry data has been resolved. Impacted services have returned to normal operation.

1. 12 juin 2026 à 04:23 UTCmonitoring

   We identified a brief period of elevated errors affecting some LaunchDarkly application requests between 7:30-7:37pm PT. The issue has recovered, and we are continuing to monitor.

2. 12 juin 2026 à 04:58 UTCresolved

   Monitoring has confirmed no further impact outside of the initially reported 7:30-7:37pm PT timeframe

1. 8 juin 2026 à 20:46 UTCidentified

   We are currently experiencing delays in event ingestion impacting multiple product areas starting at 12:40pm PT. We have identified the issue and are working on a fix. No data has been lost.

2. 8 juin 2026 à 21:24 UTCmonitoring

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

3. 9 juin 2026 à 02:03 UTCmonitoring

   We are monitoring the status of our services.

4. 10 juin 2026 à 18:54 UTCmonitoring

   We have made partial progress. Some features may show data gaps while we complete recovery. We are continuing to monitor.

5. 11 juin 2026 à 04:07 UTCmonitoring

   We are continuing to monitor for any further issues.

6. 11 juin 2026 à 04:12 UTCmonitoring

   We have made partial progress. We have identified a brief period of event data loss, and some event-based features may show incomplete data while we continue recovery. We are continuing to monitor.

7. 11 juin 2026 à 05:14 UTCmonitoring

   We have made partial progress. We identified that a small percentage of event data was lost during two windows: June 9, 11:41 - 11:59 UTC and June 10, 23:55 UTC - June 11, 00:21 UTC. Some event-based features may show incomplete data while backfills and recovery continue. We are continuing to monitor and will provide another update when recovery is complete.

8. 12 juin 2026 à 22:15 UTCmonitoring

   We have made major progress. We identified that a small percentage of event data was lost during two windows: June 9, 11:41 - 11:59 UTC and June 10, 23:55 UTC - June 11, 00:21 UTC. Some event-based features may show incomplete data while backfills and recovery continue. We are continuing to monitor and will provide another update when recovery is complete.

9. 13 juin 2026 à 13:52 UTCresolved

   This incident has been resolved.