Historique des pannes de Centrify

1. 21 octobre 2026 à 14:48 UTCinvestigating

   Nous enquêtons sur un problème touchant le service d'inventaire dans la région des États-Unis qui a une incidence sur la capacité d'ajouter ou de mettre à jour l'inventaire. La fonctionnalité de base de la plate-forme reste opérationnelle. Nous travaillons à restaurer la fonctionnalité complète dès que possible.

2. 21 octobre 2026 à 16:03 UTCresolved

   Nous sommes heureux de vous informer que l'incident affectant le service d'inventaire a été résolu. Notre équipe a mis en place un correctif, et tous les systèmes fonctionnent maintenant normalement. Nous nous excusons de tout inconvénient que cet incident pourrait avoir causé, et nous apprécions votre compréhension et votre soutien. Pour toute question ou préoccupation, veuillez contacter notre équipe de soutien à l'adresse https://support.delinea.com.

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

1. 13 octobre 2026 à 15:42 UTCinvestigating

   À partir d'environ 12h32 UTC le 13 octobre 2026, certains utilisateurs se connectant à la plate-forme Delinea avec une connexion unique SAML (SSO) n'ont pas pu compléter la connexion et ont reçu un message "Accès refusé – Erreur 15" après avoir authentifié avec leur fournisseur d'identité. Les utilisateurs qui étaient déjà inscrits, et ceux qui s'y inscrivent sans SAML SSO, n'étaient pas touchés. Le problème a été causé par une règle de sécurité chez un fournisseur de réseau de bord tiers qui a incorrectement bloqué les réponses de connexion SAML. Notre équipe d'ingénieurs a appliqué un changement de configuration à 14:11 UTC et SAML SSO connexions ont réussi normalement depuis. Si vous continuez à ressentir cette erreur, s'il vous plaît rafraîchir votre navigateur et essayer à nouveau. Nous nous excusons de l'inconvénient que cela a causé et apprécions votre patience alors que nous avons travaillé pour rétablir un service normal. Pour toute question concernant cet incident, veuillez contacter notre équipe de soutien à https://support.delinea.com.

2. 13 octobre 2026 à 15:44 UTCidentified

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

3. 13 octobre 2026 à 15:49 UTCmonitoring

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

4. 13 octobre 2026 à 16:02 UTCmonitoring

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

5. 13 octobre 2026 à 16:56 UTCresolved

   Cet incident a été résolu.

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

1. 15 octobre 2026 à 08:30 UTCresolved

   Vers 21h13 UTC le 13 octobre 2026, certains clients ont éprouvé des déconnexions prématurées lors du lancement des séances d'applications à distance. Les séances se sont terminées après environ 2 à 3 minutes. Cause racine : Une mise à jour récente de la bibliothèque FreeRDP a introduit un bug de régression qui a omis la poignée de main du client RAIL (Remote Applications Integrated Locally) pendant les sessions d'application à distance. Sans cette poignée de main, l'hôte cible a traité la session comme inactive et l'a terminée après le temps d'arrêt inactif configuré. Résolution : Le moteur PRA a été patché pour restaurer la poignée de main du client RAIL pour les connexions à distance. La fixation a été déployée et la connectivité a été rétablie pour les clients touchés par environ 12h34 UTC le 14 octobre 2026. Composantes touchées: Plateforme: Accès à distance privilégié - États-Unis, SEA, Royaume-Uni et régions de l'UA Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

2. 20 octobre 2026 à 23:36 UTCpostmortem

   ## Aperçu de l'incident Un sous-ensemble de clients utilisant Privileged Remote Access \(PRA\) Des sessions d'application à distance ont expérimenté des déconnexions de session environ 2 à 3 minutes après le lancement. Des rapports ont été reçus de clients des régions de l'EES, de l'UA, des EAU, de l'AC, du Royaume-Uni et des États-Unis. * **Début:** 13 octobre 2026, 21:13 UTC * **Fin:** 14 octobre 2026, 19:28 UTC ## Cause racine et réparation Une mise à jour prévue a été mise à jour à l'échelle régionale dans le cadre de notre service de session à distance dans le cadre du travail continu de conformité à la sécurité. Cette mise à jour comprenait une nouvelle version d'un composant de protocole de bureau à distance tiers, qui a introduit un changement de comportement qui a empêché une poignée de mains de connexion spécifique de terminer pendant l'initialisation de session. Par conséquent, les sessions touchées ont été automatiquement désactivées pendant environ 2 à 3 minutes après avoir réussi à se connecter. Comme ces déconnexions se sont déroulées proprement, sans générer d'erreurs dans les registres ou les traces du système, le problème n'a pas été détecté par les systèmes de surveillance existants avant le premier rapport du client le 13 octobre 2026. Le 14 octobre 2026, environ 19 h 28 UTC a permis d'identifier et de déployer une poignée de main pour rétablir la connexion requise dans toutes les régions touchées. Actions préventives * Élargir notre couverture automatisée des tests d'application à distance pour inclure des sessions de longue durée, de sorte que les problèmes liés au temps sont pris avant la libération. * Ajouter la surveillance pour les anomalies de durée de session, en particulier les sessions de suivi qui se déconnectent à intervalles réguliers \(p. ex. ~2 à 3 minutes\), même lorsque la déconnexion apparaît propre. Nous nous excusons sincèrement de la perturbation que cela a causée et apprécions votre patience pendant que nous avons travaillé à la résoudre.

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

1. 13 octobre 2026 à 15:26 UTCresolved

   Entre environ 12h32 UTC et 14h11 UTC le 13 octobre 2026, certains utilisateurs se connectant à la Plateforme Delinea avec une connexion unique SAML (SSO) n'ont pas pu compléter leur connexion et ont reçu un message "Accès refusé – Erreur 15" après avoir authentifié avec leur fournisseur d'identité. Les utilisateurs qui étaient déjà inscrits, et ceux qui s'y inscrivent sans SAML SSO, n'étaient pas touchés. Le problème a été causé par une règle de sécurité chez un fournisseur de réseau de bord tiers qui a incorrectement bloqué les réponses de connexion SAML. Notre équipe d'ingénieurs a appliqué un changement de configuration à 14:11 UTC et SAML SSO connexions ont réussi normalement depuis. Si vous continuez à ressentir cette erreur, s'il vous plaît rafraîchir votre navigateur et essayer à nouveau. Nous nous excusons de l'inconvénient que cela a causé et apprécions votre patience alors que nous avons travaillé pour rétablir un service normal. Pour toute question concernant cet incident, veuillez contacter notre équipe de soutien à https://support.delinea.com. Composantes touchées : Plateforme Delinea - États-Unis, Europe, Royaume-Uni, Canada, Australie, Asie du Sud-Est, Émirats arabes unis Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

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

1. 1 octobre 2026 à 21:22 UTCinvestigating

   Nous enquêtons actuellement sur un problème en cours dans la région de l'UE. Nous ferons bientôt une mise à jour.

2. 1 octobre 2026 à 22:09 UTCmonitoring

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

3. 2 octobre 2026 à 00:25 UTCresolved

   Cet incident a été résolu.

4. 14 octobre 2026 à 00:28 UTCpostmortem

   ## Aperçu de l'incident Le 1er octobre 2026, les clients de la région de l'UE ont eu des problèmes avec Secret Server Cloud \(SSC\). Les utilisateurs ne pouvaient pas lancer des sessions à partir de secrets, et des pages pour voir des détails secrets et l'historique d'audit chargé lentement ou échoué. Les tâches d'arrière-plan planifiées comme les battements de coeur, les changements de mot de passe, la découverte et les notifications ont été retardées, et certains moteurs distribués n'ont pas pu se connecter. * Heure de début: 1er octobre 2026, 08:38 UTC * Heure de fin: 2 octobre 2026, 12 h 30 UTC ## Cause racine et réparation SSC utilise un service de messagerie pour passer le travail entre ses composants. On peut citer par exemple l'enregistrement d'activités de vision secrète pour l'audit, l'exécution des tâches prévues et la préparation des lancements de sessions. Le 30 septembre 2026, le service SSC qui traite ces messages dans la région de l'UE a commencé à traiter le travail à un rythme beaucoup plus bas que la normale. Une nouvelle activité n'a cessé d'arriver au rythme normal, de sorte que les messages non traités se sont accumulés dans la file d'attente. Lorsque la file d'attente a atteint sa capacité, les messages supplémentaires ont été déplacés vers une zone de retenue pour les messages non livrables. Au cours des heures suivantes, cette zone de retenue a continué de croître jusqu'à ce que le service de messagerie atteigne sa limite de stockage. Notre équipe d'ingénierie a augmenté la capacité du service de messagerie, augmenté et redémarré les services SSC EU, et a comblé l'arriéré de messages non livrables. Une fois l'arriéré épuisé, les séances sont lancées, les pages chargées et les tâches prévues sont retournées à la normale d'ici le 2 octobre 2026, 12 h 30 UTC. Les tâches de fond retardées, y compris les battements de cœur, les changements de mot de passe et les notifications, ont été traitées automatiquement après la restauration du service. Les clients n'avaient pas besoin de prendre de mesures. Comme les services ont été restaurés immédiatement pour mettre fin à l'impact client, nous n'avons pas saisi les données diagnostiques nécessaires pour déterminer pourquoi leur débit a chuté, donc le déclencheur sous-jacent reste inconnu. La croissance de la file d'attente aurait dû être prise plus tôt. Lors d'une migration récente de notre outil d'alerte, un changement de configuration a envoyé certaines alertes métriques en nuage, y compris l'alerte de taille de la file de messagerie, à la mauvaise destination. Cette alerte s'est déclenchée le matin du 1er octobre mais n'a jamais averti notre équipe de garde. Notre correction automatisée pour d'autres types d'alerte n'a pas été affectée, ce qui a masqué l'écart. Actions préventives 1. Nous avons corrigé le routage de l'alerte le 2 octobre 2026, de sorte que ces alertes parviennent maintenant à notre équipe d'appel, et nous ajoutons des alertes canari et cardiaque qui nous avisent si l'alerte de nos outils de surveillance s'arrête ou baisse de façon inattendue. 2. Nous renforçons la façon dont nous changeons d'alerte, en testant chaque type d'alerte fin à fin avant et après tout déploiement de production. 3. Nous surveillons la récurrence du ralentissement et nous saisirons les données diagnostiques nécessaires pour en déterminer la cause si elle se reproduit. 4. Nous mettons à jour notre cycle de déploiement avec une protection qui garantit que les services de fond sont rafraîchis, même lorsqu'une version est retardée, et nous ajoutons cette étape à notre liste de vérification. Nous nous excusons pour la perturbation que cela a causé et apprécions votre patience pendant que nous l'avons résolue.

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

1. 29 septembre 2026 à 01:02 UTCidentified

   Nous enquêtons sur des rapports de connexion lente et intermittente pour les clients de la Plateforme Delinea dans les régions de l'UE, du Royaume-Uni, de l'Asie du Sud-Est et de l'Australie. À partir d'environ 23h20 UTC le 28 septembre 2026, certains utilisateurs peuvent prendre beaucoup plus de temps que d'habitude pour se connecter. Certaines tentatives de connexion peuvent échouer avec une erreur de timeout ou HTTP 504. Les utilisateurs qui sont déjà connectés peuvent également voir des réponses plus lentes lorsque leur session est validée. Notre équipe d'ingénierie est activement engagée et a identifié une dépendance dégradée affectant le service d'authentification dans ces régions. Nous travaillons actuellement sur l'atténuation. Si une inscription échoue, réessayez. Nous publierons une autre mise à jour dans les 30 minutes, ou plus tôt si nous avons de nouvelles informations.

2. 29 septembre 2026 à 01:14 UTCidentified

   Nous avons appliqué un correctif pour les clients des régions de l'UE et de l'Australie. Les taux de rendement et d'erreur d'inscription dans ces régions sont revenus à la normale à environ 01h05 UTC le 29 septembre 2026. Nous veillons à confirmer les retenues de récupération.

3. 29 septembre 2026 à 01:19 UTCmonitoring

   Nous avons appliqué une solution pour toutes les régions touchées : l'UE, le Royaume-Uni, l'Asie du Sud-Est et l'Australie. Les taux de rendement et d'erreur d'inscription sont revenus à la normale à compter du 29 septembre 2026, soit environ 01:10 UTC. Nous veillons à confirmer les retenues de récupération. Si vous avez encore du mal à vous connecter, s'il vous plaît rafraîchir votre navigateur et essayer à nouveau. Si le problème continue, contactez le support Delinea.

4. 29 septembre 2026 à 01:35 UTCresolved

   Cet incident a été résolu.

5. 6 octobre 2026 à 01:00 UTCpostmortem

   ## Aperçu de l'incident Les utilisateurs de Delinea Platform dans les régions de l'UE, du Royaume-Uni, de l'Asie du Sud-Est et de l'Australie ont connu des connexions très lentes et des défaillances intermittentes. Fonctions touchées inclus Entra ID une connexion, l'authentification de compte local, et Privileged Remote Access \(PRA\) session établissement. * Début : le 28 septembre 2026, vers 23h20 UTC * Fin : 29 septembre 2026, environ 01h10 UTC ## Cause racine et réparation Un déploiement prévu a introduit l'utilisation de répliques de cache régionales pour améliorer les performances d'authentification. La validation préalable à la publication a confirmé que les répliques étaient actives, mais une erreur de configuration du pare-feu a empêché la synchronisation des données entre le cache primaire et les répliques régionales. Les rapports de santé standard du fournisseur de cloud ont continué de montrer que les répliques étaient saines et disponibles, de sorte que le problème n'a pas été soulevé avant ou pendant la libération. Lorsque le service d'authentification a tenté de lire à partir de ces répliques, les requêtes ont été bloquées et chronométrées, entraînant des défaillances de connexion. La surveillance interne a permis de détecter les taux d'erreur élevés, et l'équipe d'ingénierie a identifié la cause profonde et a repoussé le changement. Le retour a retourné toutes les régions touchées au cache primaire et a rétabli l'authentification normale. Les répliques des caches régionaux resteront désactivées pour les régions de l'UE, du Royaume-Uni, de l'Asie du Sud-Est et de l'Australie pendant que nous évaluons les architectures alternatives. Nous avons évalué la connectivité du réseau privé entre les caches et déterminé qu'il ne répond pas à nos exigences de fiabilité. Actions préventives * Nous apportons des améliorations importantes à la façon dont le service d'authentification récupère des problèmes de connectivité cache. Le but est qu'une connexion de cache dégradée ne provoque plus de blocage ou d'échec des connexions. * Nous avons ajouté une surveillance alternative pour les défaillances de connexion, donnant une détection plus précoce des problèmes liés au cache qui ne sont pas reflétés dans les rapports de santé du fournisseur de cloud. Nous nous excusons de cette perturbation et nous nous engageons à empêcher que ces mesures ne se reproduisent.

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

1. 28 septembre 2026 à 21:35 UTCinvestigating

   Nous enquêtons sur les rapports intermittents de problèmes avec la fonctionnalité Authentificateur de l'application mobile Delinea fonctionnant comme prévu après 26.2 Déploiement. Si vous rencontrez ce problème, veuillez utiliser d'autres options de MFA jusqu'à ce que nous puissions résoudre ce problème. Notre équipe mène une enquête active et fournira une mise à jour lorsque celle-ci est disponible.

2. 29 septembre 2026 à 19:53 UTCidentified

   Le problème a été identifié et une solution est en cours d'élaboration. La réparation nécessitera un nouveau déploiement lors d'une fenêtre de maintenance du week-end. Dans l'intervalle, veuillez consulter l'article KB ci-dessous pour plus de détails sur la question et les moyens de la résoudre. https://support.delinea.com/s/article/1790702420275 Merci de votre patience. Si vous avez des questions ou une expérience de problèmes, veuillez ouvrir un dossier à https://support.delinea.com ou appelez notre ligne de soutien au +1 202-991-0540.

3. 6 octobre 2026 à 13:21 UTCresolved

   Nous sommes heureux de vous informer que l'incident touchant les services énumérés ci-dessous a été résolu. Notre équipe a mis en place un correctif, et tous les systèmes fonctionnent maintenant normalement. Nous nous excusons de tout inconvénient que cet incident pourrait avoir causé, et nous apprécions votre compréhension et votre soutien. Pour toute question ou préoccupation, veuillez contacter notre équipe de soutien à l'adresse https://support.delinea.com.

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

1. 30 septembre 2026 à 08:07 UTCresolved

   Entre environ 4h10 HAE et 6h45 HAE le 28 septembre 2026, certains clients n'ont pas pu se connecter à Secret Server Cloud à partir de certains réseaux d'entreprise. Les utilisateurs touchés ont vu des erreurs de réinitialisation de la connexion ou d'arrêt de temps lors de l'accès à leur locataire. L'accès des autres réseaux n'a pas été affecté. Les clients qui limitent l'accès du locataire à des adresses IP spécifiques n'ont pas pu se connecter pendant cette période. La question a été causée par un problème de connectivité chez un fournisseur de réseau tiers qui a affecté le trafic de certains réseaux clients de la région. Le trafic a été acheminé vers d'autres endroits et la connectivité a été rétablie pour les clients touchés par environ 6 h 45 HAE. Nous nous excusons de l'inconvénient que cela a causé et apprécions votre patience alors que nous avons travaillé pour rétablir un service normal. Pour toute question concernant cet incident, veuillez contacter notre équipe de soutien à l'adresse https://support.delinea.com . Composants affectés: Secret Server Cloud - Europe, Royaume-Uni, États-Unis, Asie Pacifique (Singapour) Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

2. 30 septembre 2026 à 08:48 UTCpostmortem

   ## Aperçu de l'incident À partir de 07:10 UTC le 28 septembre 2026, un sous-ensemble de locataires Secret Server Cloud en Europe, au Royaume-Uni, aux États-Unis et dans les régions APAC \(Singapour\) a connu des défaillances de connectivité. Les clients de certains réseaux d'entreprise rencontrent des temps de connexion ou réinitialisent des erreurs lorsqu'ils tentent de joindre leurs locataires. Les clients avec des restrictions d'accès au locataire activées n'avaient pas d'autre chemin disponible et n'ont pas pu accéder à Secret Server Cloud pendant la durée de l'incident. * Début: 28 septembre 2026, 07:10 UTC * Fin : 28 septembre 2026, 10 h 45 UTC ## Cause racine et réparation Le réseau de bord de Cloud Secret Server a connu deux problèmes distincts qui ont empêché le trafic de certains réseaux clients d'atteindre leurs locataires. La première était due à un défaut dans une mise à jour logicielle que notre fournisseur de réseau de bord déployé. Dans une condition de production spécifique qui n'a pas été identifiée dans les essais préalables au déploiement du fournisseur, le défaut a causé le redémarrage des composants de traitement du trafic à plusieurs de ses emplacements de réseau. Ces composants ont été récupérés automatiquement, et le service aux endroits touchés a été rétabli entre 07:47 et 08:20 UTC. La deuxième était due à un problème de transporteur en amont d'Internet affectant notre réseau de bord à Londres a causé la perte de paquets et les délais de connexion. En conséquence, les réseaux de clients dont le trafic transitait par Londres ont continué d'être affectés après que le premier problème eut été réglé. La connectivité a été entièrement rétablie à 10 h 45 UTC après que le trafic a été réacheminé du transporteur touché. Actions préventives * Le fournisseur a déployé un correctif pour le défaut du logiciel et renforce sa validation avant le déploiement, la résilience de son infrastructure dans tous les sites et ses mécanismes de récupération automatisés. Nous suivons ces engagements jusqu'à leur achèvement. * Nous menons un examen complet de la question du transporteur de Londres avec notre fournisseur, y compris pourquoi le trafic n'a pas été réacheminé plus tôt, et de réduire le temps d'échec afin que les futures perturbations du transporteur soient isolées rapidement. Nous nous excusons sincèrement pour la perturbation que cela a causé et pour les inconvénients que vous avez subis. Nous nous engageons à prévenir la répétition des actes susmentionnés.

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

1. 22 septembre 2026 à 12:11 UTCinvestigating

   Nous enquêtons sur un problème touchant la connexion et l'accès à Secret Server Cloud pour un sous-ensemble de clients dans les régions des États-Unis, de l'UE et des Émirats arabes unis. Notre équipe d'ingénieurs étudie activement la question et s'emploie à la résoudre le plus rapidement possible.

2. 22 septembre 2026 à 12:58 UTCmonitoring

   Nous continuons de surveiller toute autre question

3. 22 septembre 2026 à 13:07 UTCresolved

   Cet incident a été résolu.

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

1. 16 septembre 2026 à 16:37 UTCinvestigating

   Nous enquêtons sur une question touchant la connexion et l'accès à la Plateforme Delinea dans la région des États-Unis. Certains utilisateurs peuvent ne pas être en mesure de se connecter ou avoir des performances lentes lorsqu'ils accèdent à leurs locataires. Notre équipe d'ingénieurs est activement engagée. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

2. 16 septembre 2026 à 16:50 UTCidentified

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

3. 16 septembre 2026 à 17:02 UTCmonitoring

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

4. 16 septembre 2026 à 17:22 UTCmonitoring

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

5. 16 septembre 2026 à 18:32 UTCresolved

   Cet incident a été résolu.

6. 24 septembre 2026 à 21:50 UTCpostmortem

   ## Aperçu de l'incident Le 16 septembre 2026, les clients de Delinea Platform dans la région des États-Unis ont connu des défaillances de connexion et une grave lenteur lors de la signature ou de l'accès à leurs locataires. Les utilisateurs touchés ont peut-être vu des erreurs de «délai de demande en amont» sur l'écran de connexion ou ont connu de longs retards lors du chargement de leur locataire. * **Début:** 16 septembre 2026 environ 11h40 HAE \(UTC-4\) * **Fin :** 16 septembre 2026 environ 13h02 HAE \(UTC-4\) ## Cause racine et réparation La Plateforme Delinea s'appuie sur un service de cache pour prendre en charge les opérations de connexion, d'authentification et autres opérations liées à l'identité. Au cours des semaines précédentes, la demande pour ce service dans la région des États-Unis avait augmenté régulièrement avec l'utilisation croissante des plateformes, laissant une salle d'opération limitée. De plus, les services d'authentification tenaient les connexions au service de cache ouvertes au fil du temps plutôt que de les libérer, ce qui consommait progressivement sa capacité disponible. Une configuration qui distribue le trafic de lecture à travers une ressource de cache supplémentaire, qui aurait fourni une salle de tête supplémentaire, n'était pas active à l'époque. Le 16 septembre, les volumes de trafic normaux ont poussé le service de mise en cache au-delà de sa capacité d'exploitation, provoquant des demandes lentes et ratées de connexion et d'identité dans toute la région des États-Unis. Cet incident impliquait la même infrastructure de mise en cache que l'incident du [28 août 2026] (https://status.delinea.com/incidents/1s7gw9kyjwyq). Cet incident a été déclenché par un volume exceptionnellement important d'activité de synchronisation et a été traité en augmentant la capacité mémoire du service de cache. Cet incident s ' est produit dans des conditions de circulation normales, ce qui a montré que la capacité de calcul et la manutention des connexions devaient également être traitées. Notre équipe d'ingénierie a redémarré les services d'authentification concernés, qui ont libéré les connexions accumulées et restauré la fonctionnalité de connexion. Le service de mise en cache a également été étendu à un niveau supérieur qui double sa capacité de calcul, et nous avons continué à surveiller le service jusqu'à ce que la récupération complète soit confirmée. Depuis l'incident, l'utilisation du service de mise en cache est demeurée dans les limites normales d'exploitation, et le trafic de lecture est maintenant réparti sur une ressource supplémentaire de mise en cache. Actions préventives Après l'incident du 28 août 2026, nous nous sommes engagés à apporter plusieurs améliorations à cette infrastructure de mise en cache. On trouvera ci-dessous les progrès réalisés dans chacun de ces cas, ainsi que les mesures supplémentaires qui ont été identifiées à la suite de cet incident. Les travaux sur tous les points sont en cours. ** Progrès réalisés à la suite de l'incident du 28 août** * **Augmenter la capacité et la résilience de notre infrastructure de cache.** Le service américain de mise en cache a été étendu à un niveau plus élevé qui double sa capacité de calcul. Lire le trafic est maintenant distribué sur une ressource de cache supplémentaire. Nous poursuivons ce travail en déplaçant les opérations liées aux jetons vers une infrastructure de mise en cache dédiée pour d'autres salles de classe. * ** Corriger les seuils de surveillance pour détecter la pression de capacité de façon proactive**. Au cours de cet incident, notre surveillance a permis d'identifier la pression de capacité avant l'impact du client, mais les alertes n'ont pas été traitées à temps. Nous poursuivons ce travail en supprimant les alertes non actionnables pour les services d'authentification de base et en exigeant un engagement technique immédiat sur la première alerte. * **Limiter les relevés de connexion-récupération.** Ce travail a été élargi pour couvrir la façon dont les services d'authentification gèrent les connexions de cache dans l'ensemble, y compris la sortie de connexion et les paramètres de timeout, de sorte que la capacité n'est pas progressivement consommée au fil du temps. * ** Appliquer le taux limitant aux gros emplois de synchronisation.** Des limites de taux sont mises en œuvre. Nous réduisons également les demandes inutiles en volume de services intégrés à la couche de cache. **Mesures supplémentaires découlant de cet incident** * Mettre en place des redémarrages automatisés et programmés des services d'authentification en tant que sauvegarde provisoire jusqu'à ce que les améliorations de la gestion de la connexion soient déployées. Nous reconnaissons que ce n'est pas la première interruption de connexion sur la Plateforme Delinea ces dernières semaines, et nous ne le traitons pas à la légère. Au-delà des actions ci-dessus, la direction de Delinea a fait de la fiabilité de notre Plateforme une priorité parrainée par l'exécutif, avant le travail de fonctionnalité où les deux concurrents. Cela comprend une meilleure détection des problèmes touchant les flux de travail critiques tels que l'adhésion et la capacité de planification avant la croissance. Nous nous excusons sincèrement de la perturbation que cela a causé à vos opérations et nous continuerons de partager nos progrès.

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

1. 4 septembre 2026 à 22:02 UTCresolved

   Cet incident a été résolu. Nous nous excusons pour la perturbation que cela a causé. Enquête Nous enquêtons sur les rapports des locataires de la Plateforme Delinea affichant un message de locataire gelé, empêchant les utilisateurs de se connecter et d'accéder à leur environnement. La condition a commencé vers 16h49 HAE en raison d'un changement de configuration incorrect, empêchant certains clients d'accéder à leurs locataires. L'ingénierie a identifié la cause, a effectué un travail de retour à partir d'environ 17h08 HAE, et tous les locataires touchés ont été confirmés non congelés par 17h55 HAE. Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

2. 25 septembre 2026 à 05:05 UTCpostmortem

   ## Aperçu de l'incident Ce rapport porte sur deux événements connexes qui ont touché les locataires de Delinea. Le deuxième événement, du 19 au 20 septembre 2026, a été la conséquence directe d'un rétablissement incomplet à partir du premier événement survenu le 4 septembre 2026, et les deux sont documentés ensemble dans le cadre de cet incident. 1er septembre 2026 Un sous-ensemble de locataires de Delinea Platform est entré dans un état gelé, affichant un message gelé de locataire qui a empêché les utilisateurs de se connecter et d'accéder à Delinea Platform et Secret Server Cloud. **Début:** 4 septembre 2026, 16 h 15 HAE **Fin:** 4 septembre 2026, 17:55 HAE \(21:55 UTC\) 2 septembre, 2026 Un sous-ensemble de locataires Secret Server Cloud affiche un avis de suppression prévu qui empêche les utilisateurs de se connecter à Secret Server Cloud. L'inscription à la Plateforme Delinea est restée disponible. **Début:** 19 septembre 2026, 22h28 HAE \(20 septembre 02h28 UTC\) **Fin:** 20 septembre 2026, 13 h 50 HAE \(17 h 50 UTC\) ## Cause racine et réparation 1er septembre 2026 Delinea fournit des locataires qui ne sont plus sous un abonnement actif. La liste des locataires pour ce cycle a été établie à l'aide de critères de sélection qui n'évaluaient que la date d'expiration initiale de l'abonnement et qui ne tenaient pas compte des renouvellements subséquents. En conséquence, les locataires qui avaient renouvelé et qui restaient pleinement admissibles ont été traités comme ayant expiré et ont été inclus dans la liste aux côtés des locataires déprovisionnaires légitimes. Notre workflow de déprovisionnement comprend une étape de notification préalable orientée vers le client, qui affiche un avis de mise en application aux administrateurs locataires avant toute activité de suppression. Cet avis sert à la fois d'avertissement du client et de vérification interne, car tout client actif qui l'aurait reçu aurait fait surface bien avant l'exécution. Cette étape n'a pas été appliquée pour ce cycle; l'état gelé a été appliqué directement à la place, de sorte que l'erreur dans les critères de sélection n'a pas été détectée jusqu'à ce que le travail a couru. Lorsque le travail prévu a été exécuté à 16 h 15 HAE, l'État locataire gelé a été appliqué aux locataires actifs touchés. Après le premier rapport client à 16h49 HAE, Engineering a identifié la cause et a commencé un travail de retour à 17h08 HAE. Le retour effectué à 17 h 55 HAE et l'accès à l'entrée ont été confirmés chez tous les locataires touchés. Cependant, le changement du 4 septembre avait également fixé la date de fin d'abonnement des locataires de Secret Server Cloud touchés au 20 août 2026. Le retour a rétabli l'accès du locataire, mais n'a pas retourné ces dates de fin à leurs valeurs correctes, et la vérification post-recouvrement a confirmé l'accès à l'entrée seulement, pas l'exactitude des enregistrements d'abonnement sous-jacents. Cette condition est demeurée non détectée et a mené directement à l'occurrence 2. 2 septembre, 2026 Secret Server Cloud comprend un processus de cycle de vie automatisé standard qui limite l'inscription et prévoit la suppression d'un locataire 30 jours après la date de fin de son abonnement. Le 19 septembre 2026, 30 jours après la date de fin incorrecte du 20 août 2026, ce processus a permis d'identifier les locataires touchés comme étant arrivés à expiration et d'appliquer l'état de suppression prévu. Le processus du cycle de vie s'est déroulé comme prévu; la faute était les données d'abonnement incorrectes laissées en place après l'événement 1. Delinea Support a commencé à restaurer l'accès pour les locataires individuels à partir de 12h09 HAE le 20 septembre. L'ingénierie a identifié chaque locataire ayant la date de fin incorrecte puis a prolongé la date de fin d'abonnement pour tous les locataires touchés à titre de mesure temporaire, et l'accès a été rétabli dans l'ensemble de l'ensemble de 1:50 PM HAE le 20 septembre. Entre le 21 septembre et le 23 septembre 2026, Delinea a examiné individuellement chaque locataire touché par rapport à ses droits actifs et a remplacé la date de fin temporaire par la valeur correcte. Au cours de cette période, certains clients peuvent avoir observé une date de fin d'abonnement inexacte ou des détails de licence dans leurs informations de compte; cela n'a pas affecté l'accès. Si votre organisation observe une date de fin d'abonnement ou un détail de licence qui ne correspond pas à votre droit actuel, veuillez contacter notre [équipe de soutien](https://support.delinea.com/s/). Aucun locataire n'a été supprimé, et aucune donnée client n'a été supprimée, modifiée ou autrement affectée dans l'un ou l'autre cas. L'impact était limité à l'accès des locataires. Actions préventives * La déprovision des locataires en vrac a été retirée. Toutes les actions du cycle de vie des locataires en vrac sont suspendues, et la déprovision sera traitée individuellement. * Automatisez le cycle de vie du locataire à la fin des enregistrements d'abonnement actuels, y compris les renouvellements et les modifications d'abonnement, en remplaçant le processus manuel en plusieurs étapes. Chaque locataire sera validé par rapport aux enregistrements d'abonnement actifs avant toute modification d'état est appliquée. * Rendre chaque étape du cycle de vie obligatoire et non skippable, en commençant par une période de préavis pendant laquelle les administrateurs de locataires voient un avis de mise en application et toute fonctionnalité continue à fonctionner normalement. * S'assurer que les locataires gelés restent récupérables pendant une période de conservation définie avant toute suppression permanente, la restauration étant directement tirée des dossiers d'abonnement corrigés. * Renforcer les procédures de récupération des incidents afin que toute restauration de l'État locataire rétablisse et réconcilie également les dossiers d'abonnement associés, et que la récupération soit vérifiée par rapport au système d'enregistrement, et non par le seul accès à l'enregistrement, avant la clôture d'un incident. * Ajouter la surveillance interne et l'alerte pour les volumes anormaux de gel des locataires ou prévus pour les événements de suppression, et pour les modèles anormales dans les données d'abonnement, de sorte que les problèmes de ce type sont détectés par Delinea avant que les clients soient touchés. Nous nous excusons sincèrement pour les perturbations causées par les deux événements. Nous reconnaissons que le deuxième événement a résulté de notre récupération incomplète du premier, qui a étendu l'impact sur vos opérations. Rétablir l'accès était notre priorité immédiate dans chaque cas, et les mesures ci-dessus sont suivies jusqu'à leur achèvement pour s'assurer que cela ne se reproduise pas.

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

1. 28 août 2026 à 18:02 UTCinvestigating

   Nous enquêtons sur une question touchant la connexion et l'accès à la Plateforme Delinea dans la région des États-Unis. Certains utilisateurs peuvent ne pas être en mesure de se connecter ou avoir des performances lentes lorsqu'ils accèdent à leurs locataires. Dans la plupart des cas, réessayer la tentative de connexion permet aux utilisateurs d'accéder avec succès à leur locataire. Notre équipe d'ingénieurs est activement engagée. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

2. 28 août 2026 à 18:27 UTCinvestigating

   Nous continuons d'étudier les questions de connexion et d'accès touchant la plateforme Delinea dans la région américaine. Les utilisateurs touchés peuvent voir un message d'erreur « en amont de la demande de délai » lorsqu'ils tentent de se connecter, ou peuvent connaître des performances lentes lorsqu'ils accèdent à leur locataire. Notre équipe d'ingénieurs est pleinement engagée et considère cela comme une priorité absolue. Nous fournirons une mise à jour dès que de plus amples renseignements seront disponibles.

3. 28 août 2026 à 19:19 UTCidentified

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

4. 28 août 2026 à 19:33 UTCmonitoring

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

5. 28 août 2026 à 20:16 UTCresolved

   Cet incident a été résolu. Connexion et accès à la plateforme Delinea dans la région américaine sont revenus à la normale, et les utilisateurs ne devraient plus rencontrer d'erreurs ou de performances dégradées lors de la connexion. Nous poursuivons notre enquête sur la cause sous-jacente et nous partagerons une analyse des causes profondes une fois l'enquête terminée. Nous nous excusons pour la perturbation que cela a causé.

6. 10 septembre 2026 à 00:54 UTCpostmortem

   ## Aperçu de l'incident Le 28 août 2026, les clients de Delinea Platform dans la région américaine ont connu des défaillances intermittentes de connexion et des performances lentes lors de la signature ou de l'accès à leurs locataires, y compris des pages d'erreur ou de timeout sur l'écran de connexion pour certains utilisateurs. Dans certains cas, une nouvelle tentative de connexion a permis aux utilisateurs d'accéder avec succès à leur locataire. * Début: 28 août 2026 environ 17:29 UTC * Fin: 28 août 2026 environ 19:19 UTC ## Cause racine et réparation Un changement de code lié à la mise en cache qui a été effectué le 27 août, combiné à un volume exceptionnellement important d'activité de synchronisation de fond le 28 août, a dépassé la capacité d'exploitation normale de notre infrastructure de mise en cache pour les services de connexion et d'authentification. Les liaisons avec elle ont commencé à échouer et d'autres services dépendants ont tenté de récupérer ces connexions à plusieurs reprises plutôt que proprement, empêchant l'infrastructure de mise en cache de se stabiliser seule. Cela a entraîné des tentatives de connexion lentes ou ratées et des retards dans les opérations liées à l'identité dans la région des États-Unis. Notre équipe d'ingénierie a repoussé le changement de cache et a redémarré les services touchés, qui ont effacé les connexions défaillantes et ont commencé à restaurer la fonctionnalité, bien que les performances soient restées dégradées. La ressource de mise en cache a été mise à l'échelle pour rétablir des performances normales. Nous avons continué à surveiller de près le service jusqu'à ce que la récupération complète soit confirmée. Actions préventives * Accroître la capacité et la résilience de notre infrastructure de mise en cache en répartissant la charge de travail sur des ressources additionnelles. * Des seuils de surveillance corrects pour s'assurer que la pression de capacité est détectée de façon proactive avant d'avoir une incidence sur les performances de la plateforme. * Limiter les rétractations de connexion-récupération pour empêcher la récupération des connexions de la charge du système pendant un événement de contrainte. * Appliquer le taux limitant aux gros travaux de synchronisation pour éviter qu'un seul travail n'ait une incidence négative sur les performances de la plateforme. Nous nous excusons sincèrement pour la perturbation que cela a causé et pour les inconvénients que vous avez subis. Nous nous engageons à prévenir la répétition des actes susmentionnés.

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

1. 19 août 2026 à 21:47 UTCresolved

   Cet incident a été résolu. Nous nous excusons pour la perturbation que cela a causé. Enquête Nous enquêtons sur un problème où les utilisateurs des régions non américaines sont incapables d'établir de nouvelles sessions à distance. Les utilisateurs touchés reçoivent un message "Engine non disponible" lors du lancement d'une session. L'impact est limité aux clients des régions non américaines. Les locataires hébergés dans la région américaine ne sont pas touchés. Nous fournirons une mise à jour dès que nous aurons plus d'informations. Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

2. 19 août 2026 à 22:11 UTCpostmortem

   ## Aperçu de l'incident Un sous-ensemble de clients dans les régions non américaines n'ont pas pu lancer de nouvelles séances d'ADP et ont reçu une erreur « Engine non disponible ». Les séances en cours n'ont pas été modifiées. * Début: 14 août 2026, 09:46 UTC * Fin : 14 août 2026, 10 h 45 UTC ## Cause racine et réparation Une nouvelle version du service PRA a été mise en production le 14 août 2026 à 9h46 UTC. La nouvelle version n'a pas correctement appliqué une valeur de configuration requise dans l'environnement de production, ce qui a empêché le service de localiser le moteur de session pour les régions non américaines. Les clients touchés n'ont donc pas pu lancer de nouvelles sessions et ont reçu une erreur « Engine non disponible ». À la suite d'une augmentation des taux d'erreurs de backend pendant la surveillance post-déploiement, corrélée avec les rapports des clients entrants, le déploiement a été reporté à la version stable précédente. Retour terminé à 10h45 UTC. La résolution a été vérifiée par le biais de journaux backend et en confirmant que les clients touchés pouvaient lancer avec succès de nouvelles sessions. Actions préventives * Examiner le processus de déploiement pour déterminer pourquoi le problème de configuration n'a pas été détecté avant la libération de la production. * Mettre en oeuvre un modèle de déploiement échelonné pour que les nouvelles versions de service soient diffusées dans une seule région et validées avant un déploiement plus large. * Mettre en place des contrôles de santé automatisés après déploiement, y compris un lancement de session synthétique par région, qui permettent de faire la promotion et de déclencher le renversement en cas de défaillance. Nous nous excusons sincèrement de la perturbation que cela a causée et apprécions votre patience pendant que nous avons travaillé à la résoudre.

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

1. 3 août 2026 à 04:55 UTCinvestigating

   Nous enquêtons sur des rapports de performances dégradées affectant Secret Server. Certains utilisateurs peuvent être incapables d'accéder à l'interface utilisateur Vault. Les utilisateurs peuvent rencontrer l'erreur : [Federation Runtime] : distantEntryExports n'est pas défini, ce qui peut empêcher l'accès aux secrets. Notre équipe enquête activement sur la cause et travaille à rétablir un service normal. Nous fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 3 août 2026 à 14:31 UTCresolved

   Après plus ample enquête, nous avons déterminé que ce problème est isolé des déploiements sur site de Secret Server et n'affecte pas Secret Server Cloud (SSC). Aucun impact sur la SSC n'a été identifié dans les régions des États-Unis, de l'UE ou de l'EES. Cet incident est maintenant résolu.

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

1. 29 juillet 2026 à 04:12 UTCresolved

   Nous avons identifié un problème affectant Secret Server Cloud pour un sous-ensemble de clients dans la région de Singapour en raison d'une charge accrue sur l'infrastructure backend. Les utilisateurs touchés ont connu des temps de réponse lents ou des difficultés à accéder à leur instance. Ce n'était qu'un problème de performance. Ce problème a été résolu et le rendement normal a été rétabli. Nous nous excusons de tout inconvénient que cela pourrait avoir causé. Avis de remblayage : Cet incident a été ajouté à notre page de statut rétrospectivement afin de fournir un relevé exact de l'impact du service. Plus d'informations sur les incidents de remblayage sont disponibles ici .

2. 20 août 2026 à 11:49 UTCpostmortem

   Aperçu de l'incident Le 29 juillet 2026, un sous-ensemble de clients de Secret Server Cloud dans la région de Singapour a connu un problème de performance en raison d'une charge accrue sur l'infrastructure backend. Les utilisateurs touchés ont connu des temps de réponse lents ou des difficultés à accéder à leur instance. Début de l'impact: 29 juillet, 1:41AM UTC Fin de l'impact: 29 juillet, 2:32AM UTC Cause profonde Au cours de la période touchée, une ressource partagée d'appui à la région de Singapour a connu une augmentation de l'utilisation qui l'a poussée à sa capacité maximale. Un processus automatisé responsable de l'échelle des ressources pour gérer la charge accrue n'a pas été exécuté comme prévu, ce qui a entraîné une augmentation des délais de réponse pour un sous-ensemble de clients dans cette région. Actions préventives Afin d'éviter une répétition, les mesures suivantes sont mises en œuvre : * Améliorer notre processus automatisé de mise à l'échelle afin de réduire le risque que des problèmes semblables se posent à l'avenir. Nous nous excusons sincèrement pour la perturbation que cela a causé et pour les inconvénients que vous avez subis. Nous nous engageons à prévenir la répétition des actes susmentionnés.

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

1. 28 juillet 2026 à 14:03 UTCinvestigating

   Nous enquêtons sur les rapports selon lesquels certains utilisateurs de Secret Server Cloud ne peuvent se connecter et sont redirigés vers une page d'erreur. Nous travaillons activement à résoudre le problème et nous fournirons bientôt une autre mise à jour.

2. 28 juillet 2026 à 14:15 UTCidentified

   Nous avons identifié la cause profonde du problème. Un changement de configuration a empêché les locataires touchés de se connecter à la base de données, ce qui a empêché l'application de charger et d'afficher des pages d'erreur. Notre équipe d'ingénierie a appliqué un changement correctif et valide la correction. Nous fournirons bientôt une autre mise à jour.

3. 28 juillet 2026 à 16:34 UTCmonitoring

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

4. 28 juillet 2026 à 23:07 UTCresolved

   Ce problème a été résolu et les services fonctionnent normalement. Nous continuerons de surveiller pour assurer la stabilité.

5. 15 septembre 2026 à 06:39 UTCpostmortem

   ## Aperçu de l'incident Le 28 juillet 2026, un petit sous-ensemble de locataires de Secret Server Cloud n'a pas pu se connecter ni rencontrer d'erreurs lors de la navigation entre les pages. Les locataires touchés n'ont pas pu établir de connexion à leur base de données, ce qui a causé l'échec du chargement de l'application. * Début : le 28 juillet 2026, vers 03h11 UTC * Fin : le 28 juillet 2026, vers 16 h 05 UTC * Régions touchées : Très petit sous-ensemble de locataires dans plusieurs régions ## Cause racine et réparation Lors d'une phase de sortie interne, un service de support a été reconstruit et déployé dans une version qui ne correspond pas à la version en cours d'exécution dans la production de Secret Server Cloud. Les deux versions formatent les paramètres de connexion de la base de données différemment, et le format plus récent inclut un réglage que l'application de production ne reconnaît pas. Cette valeur a été écrite dans un cache interne et a servi aux locataires à mesure que leurs entrées en cache étaient rafraîchies. Comme le moment de rafraîchissement varie selon les locataires, les locataires sont devenus touchés à différents moments plutôt qu'à la fois, ce qui explique pourquoi l'impact était limité à un sous-ensemble plutôt qu'à la région complète. Notre équipe d'ingénierie a identifié la cause profonde, redéployé le service de soutien à la production de correspondance de version, et effacé les entrées de cache touchées. L'accès a été rétabli à mesure que les valeurs corrigées se propageaient, et chaque locataire touché a été validé individuellement avant la fermeture de l'incident. Actions préventives * Ajouter des tests de compatibilité automatisés et des vérifications de validation de déploiement pour attraper la configuration et les erreurs de version avant que le code atteigne la production. * Améliorer la détection des défaillances de connexion à la base de données au niveau des locataires afin que cette catégorie de problèmes soit identifiée par une surveillance interne plutôt que par des rapports de clients. * Renforcer les processus d'examen interne pour la gestion du cache et de la configuration afin de réduire les risques et l'impact de questions semblables à l'avenir. Nous nous excusons sincèrement pour la perturbation que cela a causé et pour les inconvénients que vous avez subis. Nous nous engageons à prévenir la répétition des actes susmentionnés.

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

1. 27 juillet 2026 à 18:05 UTCinvestigating

   Nous avons identifié un problème empêchant certains clients de se connecter via RDP ou de changer de mot de passe à distance. Nous travaillons activement à résoudre le problème et nous fournirons bientôt une autre mise à jour.

2. 27 juillet 2026 à 19:34 UTCidentified

   Nous avons identifié le problème empêchant certains clients de se connecter par proxy ou de changer de mot de passe à distance. Au cours de cet incident, certains clients ont également éprouvé des erreurs lors de la création de dossiers. Notre équipe d'ingénieurs a isolé la cause fondamentale et met activement en œuvre un correctif pour restaurer le service normal. Nous fournirons une autre mise à jour au fur et à mesure que les progrès se poursuivront.

3. 27 juillet 2026 à 20:10 UTCmonitoring

   Nous avons appliqué des mesures d'atténuation pour rétablir la disponibilité des services et nous surveillons activement l'environnement afin d'assurer une stabilité continue. Nous nous excusons de tout inconvénient que cela pourrait avoir causé et apprécions votre patience.

4. 27 juillet 2026 à 21:30 UTCresolved

   Les problèmes affectant nos clients Secret Server Cloud ont été résolus. Nous nous excusons de tout inconvénient que cela pourrait avoir causé.

5. 4 août 2026 à 20:24 UTCpostmortem

   ## Incident Overview On July 27, 2026, Secret Server Cloud \(US region\) customers experienced widespread failures with RDP sessions, remote password rotation, and folder creation. The root cause was a critical internal caching layer that filled up to capacity because session entries were being stored in it without expiration. As the cache filled, it began rejecting write operations, causing a backend processing service to fail. Messages continually accumulated in an internal message queue which degraded performance for all affected tenants. * Start: July 27, 2026, approximately 2:00 PM EDT * End: July 27, 2026, approximately 4:10 PM EDT * Region impacted: US ## Root Cause and Remediation The internal caching layer had been accumulating session data with no expiration for over 20 days. At the time of investigation, approximately 86% of cache entries had no expiration set. The root cause is a code-level bug that was not setting expirations properly on session entries. Once the cache reached capacity, new writes were rejected, breaking the log pipeline and cascading into broader service failures across tenants. To remediate, the caching layer was manually flushed at approximately 4:04 PM EDT, restoring write capacity and allowing the message queue to drain. A code fix to add TTL \(time-to-live\) to the affected keys has been identified and is in progress. ## Preventative Actions * Apply a code fix to add TTL to session entries and other unbounded growth keys in the caching layer, preventing recurrence regardless of deployment cadence. * Add memory utilization alerting for the caching layer at defined thresholds, so memory pressure is detected proactively before capacity is reached. * We are looking into adding a post-release action for flushing the cache as a standard step in the deployment process We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 26 juillet 2026 à 18:13 UTCresolved

   Nous sommes conscients des rapports de plusieurs clients qui connaissent des problèmes de connectivité Connector dans la région américaine. Nous avons identifié la cause comme étant l'infrastructure de réseau qui soutient le trafic Connector et avons atténué l'impact. La connectivité devrait maintenant être rétablie. Des recherches plus poussées et des modifications de l'infrastructure sont prévues pour la semaine prochaine afin d'éviter les récidives.

2. 4 août 2026 à 17:01 UTCpostmortem

   ## Incident Overview  On July 24, 2026, customers in the US region experienced Connector connectivity issues affecting authentication through the Delinea Platform. Some Connectors intermittently went offline while others in the same environment continued operating normally, with no consistent pattern distinguishing affected from unaffected Connectors. Restarting or re-registering an affected Connector did not restore connectivity.  * Start: July 24, 2026, approximately 4:50 PM ET \(8:50 PM UTC\)  * End: July 24, 2026, approximately 8:00 PM ET \(July 25, 12:00 AM UTC\)  ## Root Cause and Remediation  The root cause was overload on backend relay services that route Connector traffic to the Delinea Platform. Because impacted and unimpacted Connectors were sometimes present in the same customer environment, initial investigation focused on individual Connector configuration and network paths. Further investigation identified the issue on TCP relays in the US-West region; one affected relay was temporarily removed from the relay pool for isolation and diagnosis. This confirmed the underlying issue was load on the affected relays rather than a defect in the relay software or hardware itself.  To remediate, our team investigated and stabilized the affected relay services as they were identified, restoring Connector connectivity. Connectivity was confirmed restored the evening of July 24, and the incident was resolved by approximately 8:00 PM ET. No action was required from customers, and no customer data was lost.  ## Preventative Actions  * Added new relays in US-West and US-East to increase capacity and reduce the likelihood of relay overload recurring.  * Improve tooling for the backend relay services to make them more resilient and self-recovering under load.  * We are implementing additional monitoring of the relay services to detect this specific condition and connectivity degradation before customers are impacted.  We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 24 juillet 2026 à 16:24 UTCidentified

   Nous voulions vous fournir une mise à jour sur l'incident affectant les services énumérés ci-dessous. Notre équipe a travaillé avec diligence pour régler le problème, et nous avons fait des progrès importants. Nous apprécions votre patience et votre soutien continus alors que nous travaillons à rétablir pleinement le service normal. Pour toute question ou préoccupation, veuillez contacter notre équipe de soutien à l'adresse https://support.delinea.com.

2. 24 juillet 2026 à 16:33 UTCidentified

   Nous avons identifié la cause des erreurs intermittentes 504 / Gateway Timeout que certains clients ont connu lors de l'accès à leurs instances Delinea Platform ou lorsque des opérations basées sur des connecteurs sont en cours d'utilisation. Le problème provient de temps de réponse élevés dans un service de backend qui gère la connectivité de connecteur, ce qui provoque certaines demandes de délai. Notre équipe d'ingénierie a isolé la source et applique activement des mesures correctives pour rétablir des performances normales. Certains clients peuvent continuer à voir des délais intermittents jusqu'à ce que le correctif soit entièrement en place. Nous fournirons une nouvelle mise à jour à mesure que la situation changera.

3. 24 juillet 2026 à 22:34 UTCidentified

   Le problème a été cerné et des efforts d'assainissement sont en cours. Nous continuerons de fournir des mises à jour à mesure que nous progresserons.

4. 24 juillet 2026 à 23:48 UTCresolved

   Cet incident a été résolu.

5. 4 août 2026 à 16:40 UTCpostmortem

   ## Incident Overview  On July 24, 2026,  a subset of Delinea Platform customers in the US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing Platform. On July 24, 2026, some Delinea Platform customers in US and AU regions experienced intermittent 504 Gateway Timeout errors, resulting in temporary service disruption while accessing the platform.  Start: July 24, 2026, 11:20 AM ET  End: July 24, 2026, 3:30 PM ET  ## Root Cause and Remediation  The incident was caused by an unexpected increase in request volume generated by a Secret Server Cloud synchronization process, which exceeded the processing capacity of The Platform service. As the service became overloaded, request latency increased and some requests exceeded the gateway timeout threshold, resulting in intermittent 504 Gateway Timeout errors for a subset of Platform customers.  Our engineering team applied immediate mitigations to reduce load while working to resolve the underlying capacity constraint, and is implementing a long-term solution to improve capacity handling and prevent similar incidents. Additional monitoring will also be added to detect and respond to this type of condition more quickly.  ## Preventative Actions  * Improve capacity handling: Enhance the backend capacity to better accommodate periods of elevated request volume without impacting customer traffic.  * Optimize Secret Server Cloud synchronization: Engineering has implemented mitigations to address the immediate issue and prevent recurrence in the short term. A long-term solution is being developed to further improve the handling of synchronization workloads.   * Expand monitoring and alerting: implement additional monitoring and alerting to detect elevated request volumes and performance degradation earlier, enabling faster response and mitigation.      We sincerely apologize for the disruption this caused and the inconvenience to your operations. We are committed to preventing recurrence through the above actions.

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

1. 21 juillet 2026 à 21:55 UTCmonitoring

   Nous avons des retards dans le traitement des événements d'audit pour les clients de notre région des États-Unis. Les journaux d'audit et l'activité d'audit peuvent apparaître retardés ou incomplets dans les interfaces Delinea Platform et Secret Server Cloud. Aucun événement de vérification n'est perdu. Tous les événements sont capturés et seront traités. La fonctionnalité de base du produit, y compris l'accès secret, l'authentification et la gestion des mots de passe, n'est pas affectée. Notre équipe d'ingénierie a identifié la cause fondamentale et a élargi les ressources de base de données et de traitement pour combler l'arriéré. L'arriéré s'épuise activement.

2. 23 juillet 2026 à 15:57 UTCresolved

   L'arriéré de traitement d'événements d'audit touchant les clients de notre région des États-Unis est a été entièrement éliminé. Les registres de vérification sont maintenant à jour. Aucun événement de vérification n'a été perdu pendant cette période. Merci de votre patience.

3. 20 août 2026 à 11:48 UTCpostmortem

   Aperçu de l'incident Le 20 juillet 2026, un sous-ensemble de clients de Delinea Platform dans la région des États-Unis a connu des retards dans le traitement des événements d'audit, ce qui a entraîné un décalage entre le moment où les actions ont eu lieu et le moment où les événements d'audit correspondants sont apparus dans les journaux. * Début: 20 juillet, 2026, 10:54 UTC * Fin : 23 juillet 2026, 15 h 58 UTC ### Cause racine et réparation L'incident a été causé par une augmentation du volume d'événements d'audit suite à une récente publication de Secret Server, qui a dépassé la capacité de traitement du pipeline d'événements d'audit dans la région des États-Unis. À mesure que le volume augmentait, les événements étaient en attente pour le traitement plutôt que pour la livraison en temps réel, ce qui causait un arriéré et un retard correspondant dans la disponibilité du registre d'audit. Aucun événement de vérification n'a été perdu durant cet incident. Notre équipe d'ingénierie a augmenté la capacité de traitement des données sous-jacentes pour faire face à l'arriéré tout en surveillant la profondeur de la file et les taux de traitement. Au 23 juillet 2026, tous les événements retardés avaient été entièrement traités, les registres de vérification étaient à jour et les opérations normales avaient repris. Actions préventives * Améliorer l'échelle automatisée du pipeline d'événements de vérification afin qu'il puisse absorber les augmentations de volume sans créer d'arriéré ou retarder la disponibilité du journal. * Améliorer la surveillance et alerter le volume de traitement des vérifications et la profondeur de la file d'attente pour détecter les retards potentiels plus tôt et répondre avant que les clients soient touchés. Nous nous excusons sincèrement pour la perturbation que cela a causé et pour les inconvénients que vous avez subis. Nous nous engageons à prévenir la répétition des actes susmentionnés.

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