Historique des pannes de Socure

1. 27 octobre 2026 à 17:08 UTCresolved

   Le 27 octobre 2026, certains clients n'ont pas été en mesure de recevoir RiskOS Sandbox webhooks. Le problème a été causé par des configurations de webhook invalides qui ont causé l'envoi de notification Sandbox pour arrêter le traitement des événements. Les configurations malformées ont depuis été corrigées. Tous les traitements ont récupéré et la livraison webhook a repris avec succès

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

1. 23 octobre 2026 à 21:00 UTCmonitoring

   SSA connaît actuellement un événement touchant plusieurs applications et services, notamment le service de vérification des numéros de sécurité sociale par consentement électronique (eCBSV). Un petit nombre de transactions sont touchées puisque la perturbation a été signalée pour la première fois à environ 16 h 47 (HE) le 23 octobre 2026. Nous partagerons une autre mise à jour une fois que nous aurons reçu l'avis que le service a été restauré, et eCBSV fonctionne à nouveau normalement.

2. 23 octobre 2026 à 21:12 UTCresolved

   Vers 4 h 56 (HE), le service a été rétabli et le système eCBSV fonctionne normalement actuellement. Nous nous excusons pour les inconvénients que cela peut avoir causés.

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

1. 19 octobre 2026 à 19:04 UTCinvestigating

   Nous enquêtons actuellement sur un problème qui cause une latence intermittente avec l'affichage et le téléchargement de DocV Images pour un petit pourcentage des transactions terminées. Il n'y a pas d'impact sur DocV ni sur les évaluations pour le moment, mais les images peuvent prendre plus de temps à apparaître.

2. 19 octobre 2026 à 21:15 UTCmonitoring

   Notre équipe a pris des mesures pour atténuer la latence éprouvée pour l'affichage et les téléchargements d'images DocV. Il n'y a toujours aucun impact sur les évaluations DocV à l'heure actuelle et l'équipe continuera de surveiller la situation. Nous fournirons une autre mise à jour une fois que tous les impacts auront été résolus.

3. 20 octobre 2026 à 01:57 UTCresolved

   Ce problème a été résolu, et nous surveillons le rendement pour nous assurer que les services demeurent stables. Nous nous excusons de tout inconvénient que cela pourrait avoir causé.

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

1. 18 octobre 2026 à 19:33 UTCresolved

   SSA a connu un événement touchant plusieurs applications et services, y compris le service de vérification des numéros de sécurité sociale par consentement électronique (eCBSV). Un petit nombre de transactions ont été touchées lorsque la perturbation a commencé à environ 14 h 50 (HE) le 18 octobre 2026 et a été réglée à environ 15 h 10. Le service a été rétabli, et eCBSV fonctionne normalement actuellement.

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

1. 16 octobre 2026 à 20:20 UTCinvestigating

   À partir de 3h00 HAE, certains clients peuvent éprouver des erreurs intermittentes ou des demandes ratées lors de l'utilisation des API d'évaluation RiskOS. Nous avons identifié un problème de base de données et nous travaillons activement à le résoudre. Nous nous excusons pour la perturbation et apprécions votre patience pendant notre enquête.

2. 16 octobre 2026 à 21:18 UTCmonitoring

   Nous avons pris une mesure provisoire, et le taux d'erreur élevé a diminué. Nous n'avons pas observé d'erreurs connexes au cours des 15 dernières minutes. Nous amenons l'incident à la surveillance pendant que nous continuons à travailler à une résolution complète. Nous partagerons une autre mise à jour lorsque la situation changera.

3. 16 octobre 2026 à 22:59 UTCmonitoring

   Nous apprécions votre patience car notre équipe suit toujours la situation de près. Les taux d'erreurs ont diminué alors que nous continuons de travailler à une résolution complète.

4. 17 octobre 2026 à 02:10 UTCresolved

   L'incident a été résolu et nous ne voyons plus d'erreurs. Les services fonctionnent normalement, et nous continuerons à surveiller les performances. Nous apprécions votre patience pendant notre travail.

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

1. 16 octobre 2026 à 02:23 UTCresolved

   Les services Socure RiskOS et ID+ ont été restaurés. Une erreur dans un déploiement a causé une augmentation temporaire des taux d'erreur de nos services entre 18:12 et 18:56 heure de l'Est. L'erreur a été corrigée et les services sont stables maintenant. Nous comprenons que cette panne est inacceptable et une ACR complète sera disponible dès que l'analyse complète de la question sera terminée.

2. 17 octobre 2026 à 01:42 UTCpostmortem

   ## **Analyse des causes de la maladie** **Incident :** Sortie des API de Socure **Date Gamme:** 15-Oct-2026 **Impact:** Interruption en service pour les API Socure ** État :** Résolue ### **1. Résumé** Le 15-Oct-2026, entre 18:12 et 19:00 heure de l'Est Socure a connu une interruption de ses API RiskOS et ID\+, causant des erreurs et des délais aux utilisateurs. La première phase s'est déroulée de 18:12 à 18:20, et a été une interruption majeure pour pratiquement tous les services. La deuxième phase de la panne a duré de 18 h 20 à 19 h, et a été une panne partielle pour les services qui dépendent des données de KYC, où les clients ont vu des taux d'erreur et des latences élevés pour certains services, mais le trafic était toujours desservi. **2. Calendrier** **Date / heure \(ET\)** Un changement de nettoyage de routine est fusionné, déplaçant une repo source d'un dépôt de code à un autre. Un bug dans notre outil de révision masque la portée du changement. **18:13**.ArgoCD redémarre la plupart des services dans un cluster Kubernetes majeur. **18:20**= Tous les modules de service sont en cours d'exécution. Service d'API partiel restauré, bien que les services KYC voient toujours un taux d'erreur élevé. **18:21**= L'inondation du trafic de démarrage envahit notre service de recherche KYC. Les taux d'erreur augmentent. **18:42**SRE diagnostique l'échec en cascade qui affecte KYC Search et bloque le trafic pour qu'il puisse monter. **18:56**.Le service de recherche de KYC est complet, et SRE lui retourne le trafic. Les services en aval se stabilisent. **19:00**= Tout le trafic circulant normalement, incident déclaré stable. La cause profonde * ** Cause principale de la racine :** Dans le cadre d'une migration en cours, un SRE sur appel a changé l'ArgoCD, le système que nous utilisons pour gérer les grappes de kubernetes Socure gère ses services. Le changement a été étendu à un seul groupe, a été examiné attentivement avant de pousser, n'a causé aucun problème dans d'autres environnements dans lesquels il a été testé, et aurait dû n'avoir aucun impact visible. Malheureusement, le changement a mis à jour un cadre qui ne figurait pas dans l'examen du changement. Ce cadre historique régissait les services gérés par ArgoCD et retirait de nombreux services en direct de ArgoCD. En conséquence, ArgoCD a retiré ces services de la production brièvement, avant que le réglage ne soit corrigé. * ** Facteurs de conversion :** Le service de recherche KYC est un élément moteur de l'infrastructure de Socure qui fournit des services à plusieurs de nos produits internes. Lorsque ce service a redémarré de zéro en même temps que tous les clients du service, un petit nombre de modules du service s'est écrasé sous charge. Cela a augmenté la charge sur les autres gousses, dont certaines se sont écrasées à leur tour. Cet échec en cascade a empêché le service de revenir seul comme le faisaient les autres infrastructures de la Société. Le diagnostic de ce mode de défaillance séparé a pris plus de temps et l'assainissement a corrigé les erreurs restantes après l'incident initial. Résolution** Le changement d'ArgoCD a été rétabli immédiatement, ce qui a fait revenir les services à leur état antérieur. Le service de recherche de KYC a nécessité des efforts manuels pour empêcher le trafic de l'atteindre jusqu'à ce qu'une majorité de pods dans le service puisse apparaître. Une fois le service en bonne santé, nous pourrions y rétablir le trafic et résoudre l'incident global. 5. Mesures correctives et préventives** 6. Enseignements tirés** * L'outillage de la Socure pour voir les changements qu'il apporte à la production ne fonctionnait pas correctement. Nous revoyons ces outils pour nous assurer qu'ils fonctionnent correctement dans tous les cas d'utilisation et pour corriger tout cas comme celui-ci où la portée d'un changement n'est pas claire. * Augmenter le processus d'examen des changements avec le soutien des agents. Bien que, dans le cas présent, le changement particulier ne soit pas visible dans le plan, le fait d'avoir un examinateur supplémentaire appuyé par un modèle de formation détaillé aidera à s'assurer que les problèmes sont pris en compte avant la soumission. * Même les changements qui semblent n'avoir aucun impact, lorsqu'ils sont apportés au système de gouvernance pour nos emplois de production, peuvent être risqués et devraient être déplacés plus loin des heures d'ouverture américaines. * Notre service de recherche KYC est vulnérable à un problème de "thundering-herd" quand il reçoit un flux de trafic complet quand il n'est pas entièrement en ligne. Nous devons renforcer nos disjoncteurs pour éviter que ce problème ne se reproduise. * Nous gérons trop de nos services API de base dans un seul cluster de kubernetes. Même si ce cluster est réparti dans plusieurs zones de disponibilité, le plan de contrôle partagé crée un rayon de bouffée trop élevé pour les changements à ce cluster. ### **7. Prochaines étapes et engagement continu** Socure comprend que nos clients comptent sur nous comme un fournisseur clé dans les flux d'affaires critiques, et que cette interruption de service n'est pas acceptable. Nous nous excusons de l'impact que cette question a causé et nous nous engageons à ne pas y revenir. À cette fin, nous fournirons des détails sur nos plans de ré-archivage de notre mise en page d'ici novembre, ainsi que d'améliorer la résilience du service de recherche KYC au premier trimestre de l'année prochaine.

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

1. 15 octobre 2026 à 23:15 UTCresolved

   Les services Socure RiskOS et ID+ ont été restaurés. Une erreur dans un déploiement a causé une augmentation temporaire des taux d'erreur de nos services entre 18:12 et 18:56 heure de l'Est. L'erreur a été corrigée et les services sont stables maintenant. Nous comprenons que cette panne est inacceptable et une ACR complète sera disponible dès que l'analyse complète de la question sera terminée.

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

1. 15 octobre 2026 à 22:39 UTCinvestigating

   Nous vivons actuellement un incident actif qui affecte la disponibilité des services. Nous enquêtons actuellement sur la question et fournirons des mises à jour dès que nous aurons des renseignements supplémentaires.

2. 15 octobre 2026 à 23:04 UTCmonitoring

   Les services Socure RiskOS et ID+ ont été restaurés. Une erreur dans un déploiement a causé une augmentation temporaire des taux d'erreur de nos services entre 18:20 et 18:56 heure de l'Est. L'erreur a été corrigée et les services sont stables maintenant. Nous comprenons que cette panne est inacceptable et une ACR complète sera disponible dès que l'analyse complète de la question sera terminée.

3. 15 octobre 2026 à 23:04 UTCmonitoring

   Les services Socure RiskOS et ID+ ont été restaurés. Une erreur dans un déploiement a causé une augmentation temporaire des taux d'erreur de nos services entre 18:12 et 18:56 heure de l'Est. L'erreur a été corrigée et les services sont stables maintenant. Nous comprenons que cette panne est inacceptable et une ACR complète sera disponible dès que l'analyse complète de la question sera terminée.

4. 15 octobre 2026 à 23:08 UTCresolved

   Les services Socure RiskOS et ID+ ont été restaurés. Une erreur dans un déploiement a causé une augmentation temporaire des taux d'erreur de nos services entre 18:12 et 18:56 heure de l'Est. L'erreur a été corrigée et les services sont stables maintenant. Nous comprenons que cette panne est inacceptable et une ACR complète sera disponible dès que l'analyse complète de la question sera terminée.

5. 17 octobre 2026 à 01:30 UTCpostmortem

   ## **Analyse des causes de la maladie** **Incident :** Sortie des API de Socure **Date Gamme:** 15-Oct-2026 **Impact:** Interruption en service pour les API Socure ** État :** Résolue ### **1. Résumé** Le 15-Oct-2026, entre 18:12 et 19:00 heure de l'Est Socure a connu une interruption de ses API RiskOS et ID\+, causant des erreurs et des délais aux utilisateurs. La première phase s'est déroulée de 18:12 à 18:20, et a été une interruption majeure pour pratiquement tous les services. La deuxième phase de la panne a duré de 18 h 20 à 19 h, et a été une panne partielle pour les services qui dépendent des données de KYC, où les clients ont vu des taux d'erreur et des latences élevés pour certains services, mais le trafic était toujours desservi. **2. Calendrier** **Date / heure \(ET\)** Un changement de nettoyage de routine est fusionné, déplaçant une repo source d'un dépôt de code à un autre. Un bug dans notre outil de révision masque la portée du changement. **18:13**.ArgoCD redémarre la plupart des services dans un cluster Kubernetes majeur. **18:20**= Tous les modules de service sont en cours d'exécution. Service d'API partiel restauré, bien que les services KYC voient toujours un taux d'erreur élevé. **18:21**= L'inondation du trafic de démarrage envahit notre service de recherche KYC. Les taux d'erreur augmentent. **18:42**SRE diagnostique l'échec en cascade qui affecte KYC Search et bloque le trafic pour qu'il puisse monter. **18:56**.Le service de recherche de KYC est complet, et SRE lui retourne le trafic. Les services en aval se stabilisent. **19:00**= Tout le trafic circulant normalement, incident déclaré stable. La cause profonde * ** Cause principale de la racine :** Dans le cadre d'une migration en cours, un SRE sur appel a changé l'ArgoCD, le système que nous utilisons pour gérer les grappes de kubernetes Socure gère ses services. Le changement a été étendu à un seul groupe, a été examiné attentivement avant de pousser, n'a causé aucun problème dans d'autres environnements dans lesquels il a été testé, et aurait dû n'avoir aucun impact visible. Malheureusement, le changement a mis à jour un cadre qui ne figurait pas dans l'examen du changement. Ce cadre historique régissait les services gérés par ArgoCD et retirait de nombreux services en direct de ArgoCD. En conséquence, ArgoCD a retiré ces services de la production brièvement, avant que le réglage ne soit corrigé. * ** Facteurs de conversion :** Le service de recherche KYC est un élément moteur de l'infrastructure de Socure qui fournit des services à plusieurs de nos produits internes. Lorsque ce service a redémarré de zéro en même temps que tous les clients du service, un petit nombre de modules du service s'est écrasé sous charge. Cela a augmenté la charge sur les autres gousses, dont certaines se sont écrasées à leur tour. Cet échec en cascade a empêché le service de revenir seul comme le faisaient les autres infrastructures de la Société. Le diagnostic de ce mode de défaillance séparé a pris plus de temps et l'assainissement a corrigé les erreurs restantes après l'incident initial. Résolution** Le changement d'ArgoCD a été rétabli immédiatement, ce qui a fait revenir les services à leur état antérieur. Le service de recherche de KYC a nécessité des efforts manuels pour empêcher le trafic de l'atteindre jusqu'à ce qu'une majorité de pods dans le service puisse apparaître. Une fois le service en bonne santé, nous pourrions y rétablir le trafic et résoudre l'incident global. 5. Mesures correctives et préventives** 6. Enseignements tirés** * L'outillage de la Socure pour voir les changements qu'il apporte à la production ne fonctionnait pas correctement. Nous revoyons ces outils pour nous assurer qu'ils fonctionnent correctement dans tous les cas d'utilisation et pour corriger tout cas comme celui-ci où la portée d'un changement n'est pas claire. * Augmenter le processus d'examen des changements avec le soutien des agents. Bien que, dans le cas présent, le changement particulier ne soit pas visible dans le plan, le fait d'avoir un examinateur supplémentaire appuyé par un modèle de formation détaillé aidera à s'assurer que les problèmes sont pris en compte avant la soumission. * Même les changements qui semblent n'avoir aucun impact, lorsqu'ils sont apportés au système de gouvernance pour nos emplois de production, peuvent être risqués et devraient être déplacés plus loin des heures d'ouverture américaines. * Notre service de recherche KYC est vulnérable à un problème de "thundering-herd" quand il reçoit un flux de trafic complet quand il n'est pas entièrement en ligne. Nous devons renforcer nos disjoncteurs pour éviter que ce problème ne se reproduise. * Nous gérons trop de nos services API de base dans un seul cluster de kubernetes. Même si ce cluster est réparti dans plusieurs zones de disponibilité, le plan de contrôle partagé crée un rayon de bouffée trop élevé pour les changements à ce cluster. ### **7. Prochaines étapes et engagement continu** Socure comprend que nos clients comptent sur nous comme un fournisseur clé dans les flux d'affaires critiques, et que cette interruption de service n'est pas acceptable. Nous nous excusons de l'impact que cette question a causé et nous nous engageons à ne pas y revenir. À cette fin, nous fournirons des détails sur nos plans de ré-archivage de notre mise en page d'ici novembre, ainsi que d'améliorer la résilience du service de recherche KYC au premier trimestre de l'année prochaine.

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

1. 15 octobre 2026 à 14:52 UTCidentified

   Nous sommes actuellement confrontés à une panne imprévue affectant le module eCBSV en raison des réponses SSA, entraînant des erreurs 5xx. Socure a communiqué avec le fournisseur pour enquêter sur la question et déterminer quand le service devrait être rétabli.

2. 15 octobre 2026 à 14:55 UTCmonitoring

   Les taux d'erreur ont diminué au cours des dernières minutes. Nous surveillons ces taux et nous attendons la réponse de nos fournisseurs.

3. 15 octobre 2026 à 15:59 UTCresolved

   SSA a connu un événement touchant plusieurs applications et services, y compris le service de vérification des numéros de sécurité sociale par consentement électronique (eCBSV). La perturbation a commencé vers 10 h 19 (HE) le 15 octobre 2026 et a été résolue vers 10 h 41 (HE). Le service a été rétabli, et eCBSV fonctionne normalement actuellement.

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

1. 9 octobre 2026 à 23:25 UTCresolved

   Nous avons connu des défaillances de transaction élevées affectant Watchlist Plus et Watchlist Premier. Le problème a été résolu, et nous surveillons le rendement pour nous assurer que les services demeurent stables. Nous nous excusons de tout inconvénient que cela pourrait avoir causé.

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

1. 22 septembre 2026 à 12:26 UTCidentified

   Nous enquêtons sur un problème qui cause des retards dans la prise en compte des mises à jour de cas dans l'assurance-chômage RiskOS Case Management. Notre équipe d'ingénierie travaille activement à identifier la cause profonde et à restaurer le comportement normal de mise à jour. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles. Cela n'a aucune incidence sur les demandes d'évaluation de l'API.

2. 22 septembre 2026 à 13:22 UTCmonitoring

   Nous avons identifié la cause profonde du problème touchant les mises à jour de l'assurance-chômage RiskOS Case Management. Ce problème se limite à un sous-ensemble de cas et affecte spécifiquement la fonctionnalité de recherche de cas, qui peut temporairement afficher des états de cas dépassés. Veuillez noter que les données sur l'état des cas affichées dans la liste des cas et les pages de détails des cas individuels sont exactes et reflètent le dernier état. Notre équipe d'ingénierie a déployé un correctif pour tous les nouveaux cas mis à jour et s'emploie activement à resynchroniser les autres cas touchés afin d'assurer la cohérence des données dans toute la recherche. Nous fournirons une autre mise à jour une fois que le comportement normal est complètement restauré.

3. 22 septembre 2026 à 14:09 UTCresolved

   La question touchant les mises à jour de l'état des dossiers a été résolue. Tous les nouveaux cas sont traités correctement. Nous nous excusons sincèrement de tout inconvénient que cela pourrait avoir causé et apprécions votre patience pendant que notre équipe travaillait à le résoudre.

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

1. 21 septembre 2026 à 11:57 UTCresolved

   Entre 6h28 et 6h57 HE le 21 septembre, un problème lors d'une activité opérationnelle a provoqué une nouvelle transmission de certaines notifications de webhook associées à d'anciennes évaluations du mois dernier. Les évaluations en cours et le traitement du webhook n'ont pas été touchés. La question a été réglée. Nous nous excusons pour toute confusion ou tout bruit supplémentaire que cela pourrait avoir causé.

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

1. 16 septembre 2026 à 14:36 UTCinvestigating

   Nous enquêtons sur les retards affectant le traitement par lots sur le tableau de bord. Les clients peuvent subir un traitement retardé pendant que nous examinons le problème.

2. 16 septembre 2026 à 14:49 UTCresolved

   Cet incident a été résolu.

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

1. 16 septembre 2026 à 09:39 UTCidentified

   Nous observons une latence accrue affectant certains clients qui utilisent nos produits frauduleux et synthétiques. Notre équipe enquête activement sur le problème. Les demandes d'API sont remplies avec succès, et nous n'observons aucune défaillance d'API à ce moment. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 16 septembre 2026 à 10:07 UTCmonitoring

   Nous constatons une amélioration de la latence affectant certains clients utilisant nos produits frauduleux et synthétiques. Nous continuerons de suivre de près la situation.

3. 16 septembre 2026 à 10:12 UTCresolved

   Le problème de la fraude et des services synthétiques a été résolu et le service a repris ses activités normales. Les clients ne devraient plus subir d'augmentation de la latence ou de retards lors de l'accès aux services de fraude et de synthèse

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

1. 10 septembre 2026 à 19:39 UTCresolved

   Entre 8h30 et 14h00 HNE, nous avons observé une augmentation des taux d'erreur 5xx, ce qui a entraîné des erreurs intermittentes ou des demandes défectueuses pour certains clients. L'impact global a été minime, soit moins de 0,01 %. Le taux d'erreur est revenu à la normale depuis. Cette question est actuellement entièrement résolue. Nous nous excusons de toute perturbation et apprécions votre patience.

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

1. 9 septembre 2026 à 11:37 UTCresolved

   Entre 7h00 et 7h20 HNE, nous avons observé une augmentation des taux d'erreur 5xx, ce qui peut avoir entraîné des erreurs intermittentes ou des demandes défectueuses pour certains clients. Depuis, le taux d'erreur est revenu à la normale, et nous enquêtons sur la cause fondamentale pour nous assurer d'avoir entièrement résolu le problème. Nous nous excusons de toute perturbation et apprécions votre patience.

2. 15 septembre 2026 à 18:15 UTCpostmortem

   **Analyse des causes des blessures** **Incident :** Erreurs 5xx élevées intermittentes dans les services **Date Gamme:** 9 septembre 2026, 7h00 – 9h20 HAE \(environ 2 heures 20 minutes d'impact intermittent\) **Impact:** Certaines demandes soumises à l'API EmailAuthScore et aux services connexes ont retourné des réponses d'erreur intermittentes. L'impact était intermittent plutôt que continu et se limitait aux fenêtres définies décrites dans le calendrier ci-dessous. ** État :** Résolue ### **1. Résumé** Le 9 septembre 2026, une augmentation prévue de la capacité de traitement de l'arrière-plan a entraîné une augmentation de la charge de raccordement d'un élément d'infrastructure interne utilisé pour soutenir le traitement en aval de plusieurs services. Cette composante a atteint un seuil de capacité interne, ce qui a entraîné des retards de traitement et des réponses intermittentes à des erreurs sur l'API EmailAuthScore et les services connexes pour un sous-ensemble de demandes. La question a été identifiée par une combinaison de surveillance interne et de rapports pendant la fenêtre d'impact. L'ingénierie de la Socure corroborait les erreurs avec le changement récent de capacité et les retournait, ce qui stoppait l'augmentation initiale des erreurs. Une seconde augmentation connexe des erreurs s'est alors produite lorsqu'un changement de capacité distinct, effectué plus tôt pour un service interne différent, a imposé une charge supplémentaire sur la même composante partagée; l'ingénierie a appliqué d'autres mesures d'atténuation, après quoi tous les services touchés sont revenus à une exploitation normale et stable. La section 5 décrit les mesures correctives et préventives à prendre.Socure s'engage, en priorité, à améliorer la visibilité dans la capacité de l'infrastructure et à éviter que des retards dans un seul élément interne n'affectent le traitement des demandes par les clients. **2. Calendrier** **Date / heure \(EDT\)** - Oui. **Le 9 septembre, 2026 07:00 Après une augmentation prévue de la capacité de traitement de backend, l'API EmailAuthScore a commencé à renvoyer des réponses d'erreur intermittentes. Autres **Le 9 septembre, 2026 07:20 Le changement récent de capacité a été rétabli; les taux d'erreur sont revenus à la normale. **Le 9 septembre, 2026 08:45 Un changement de capacité séparé effectué plus tôt pour un service interne différent a placé une charge supplémentaire sur le même composant interne partagé, et l'API EmailAuthScore a de nouveau commencé à renvoyer des réponses d'erreur intermittentes. Autres **Le 9 septembre, 2026 09:20 **= Des mesures d'atténuation supplémentaires ont été appliquées; les taux d'erreur sont revenus à la normale et sont demeurés stables. **Le 9 septembre, 2026 01:13 Par précaution, Socure a temporairement réacheminé une partie du traitement interne du composant interne touché afin de compléter en toute sécurité l'augmentation de capacité restante. Aucune autre erreur n'a été observée après ce changement. La cause profonde * ** Cause principale de la racine :** Dans le cadre des travaux prévus pour accroître la capacité du système avant la demande prévue, Socure a augmenté la capacité de traitement des services de soutien. Ce changement a augmenté le nombre de connexions à un composant de messagerie interne utilisé pour le traitement en aval de ces services. Cette composante a atteint une limite de capacité de connexion interne, ce qui a entraîné des retards de connexion et de traitement. Ces retards ont entraîné des latences supplémentaires et, dans certains cas, une contrepression dans le traitement des demandes, ce qui a contribué à des taux d'erreur intermittents élevés sur l'API EmailAuthScore et les services connexes pour un sous-ensemble de demandes durant les fenêtres d'impact décrites ci-dessus. * ** Facteurs de conversion :** * Une augmentation soudaine de la demande en matière de capacités d'infrastructure a dépassé la capacité qui n'était pas immédiatement disponible dans la composante messagerie interne. Résolution** Après avoir constaté que les taux d'erreur élevés étaient liés au changement récent de capacité, l'ingénierie de Socure a repris le changement, ce qui a mis fin à l'augmentation initiale des erreurs. Une seconde augmentation connexe des erreurs s'est alors produite lorsqu'un changement de capacité distinct, effectué plus tôt pour un service interne différent, a imposé une charge supplémentaire sur le même composant partagé. Le génie a appliqué d'autres mesures d'atténuation, y compris le déplacement temporaire d'une partie du traitement interne de la composante touchée pour les services touchés. À la suite de ces actions, tous les services touchés sont revenus à une exploitation normale et stable, ce que la Société a confirmé par une surveillance continue. (en milliers de dollars) 5. Mesures correctives et préventives** **Statut** - Oui. Optimiser l'utilisation de la capacité d'infrastructure. Fait Augmenter la capacité de l'infrastructure de messagerie. Fait Améliorer la surveillance et l'alerte des capacités Ajouter une surveillance et des alertes proactives pour identifier les contraintes potentielles en matière de capacité d'infrastructure avant qu'elles n'affectent le rendement du service. Autres En cours. ETA 30 sept. 2026. 6. Enseignements tirés** * Un suivi proactif de la santé des infrastructures doit être mis en place avant les changements de capacité, et non seulement au niveau de l'application. ### **7. Prochaines étapes et engagement continu** Nous nous engageons à : * Remplir les mesures correctives et préventives énumérées à la section 5. * Améliorer la visibilité dans la santé et la capacité des infrastructures internes essentielles avant les activités futures d'échelle. * Fournir une mise à jour de suivi une fois toutes les mesures correctives terminées.

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

1. 8 septembre 2026 à 14:54 UTCinvestigating

   Nous enquêtons actuellement sur une question qui a eu un impact sur les services de surveillance DocV et Watchlist où des erreurs ont été observées aujourd'hui 8 septembre, de 09h05 HNE à 09h30 HNE. Le système s'est rétabli, nous travaillons actuellement à déterminer une cause profonde.

2. 8 septembre 2026 à 15:41 UTCresolved

   La question ayant une incidence sur les services de surveillance DocV et Watchlist le 8 septembre a été résolue. Aucun impact client n'a été observé depuis 10:35 AM EST. Nous nous excusons pour toute perturbation que cela aurait pu causer.

3. 17 septembre 2026 à 19:47 UTCpostmortem

   #### **Analyse des causes de la maladie** **Incident:** Interruption de service affectant l'accès aux données des comptes **Date Gamme:** 8 septembre 2026 \(10:04 à 10:31 HAE\) **Impact:** DocV et Watchlist Monitors ** État :** Résolue 1. Résumé Un épuisement inattendu de la capacité de base de données backend a temporairement empêché notre plateforme de récupérer des informations de compte pour un sous-ensemble de demandes de clients. Pendant la fenêtre d'incident \(10:04 AM à 10:31 AM EDT de 8-Sep-2026\), certaines des demandes du client ont connu des taux d'erreur élevés lors de la tentative de demander des détails de compte. Après une mise à jour de routine, les connexions simultanées des environnements de sauvegarde ont dépassé les seuils normaux, saturant la capacité de base de données disponible. Les équipes d'ingénierie ont déconnecté en toute sécurité les environnements redondants et rafraîchi les connexions actives, en rétablissant la pleine réactivité et la stabilité du système. 2. Calendrier **Date/heure \(ET\)** - Oui. Première erreur Accident signalé à 10 h 17 HNE, 8 septembre 2026 Redondant piscine de connexion environnementale isolée L'incident a été résolu. 3. Cause profonde * ** Cause principale de la racine :** Lors d'une mise à jour programmée du système, une rétention de connexion élevée entre les environnements de déploiement a conduit à une saturation du pool de connexion à la base de données. Sous le trafic de pointe, cela a causé des retards de traitement et des délais de demande pour les services de plate-forme dépendants. * ** Facteurs de conversion :** * Les paramètres de temps de connexion rigide ont retardé la publication en temps voulu des allocations de base de données par environnement passif. * Un nœud de base de données inadéquat a empêché le traitement sans heurt des connexions supplémentaires générées par l'environnement de veille. * ** Facteurs non contributifs :** * Aucune 4. Résolution L'intégrité complète du service a été rétablie grâce aux mesures immédiates suivantes : 1. Isoler les connexions d ' environnement non actives pour libérer immédiatement la capacité de la base de données. 2. Effectuer une remise en marche des nœuds de service actifs pour rétablir des lignes de base de données claires. (en milliers de dollars) 5. Mesures correctives et préventives **Statut** - Oui. Améliorer les modèles d'accès aux données Améliorer la stratégie de mise en cache et les modèles d'accès aux données dans les services internes qui dépendent des données comptables. 15 octobre 2026 Améliorer la gestion du cycle de vie de la connexion et les routines de nettoyage automatisées pour les tâches de fond inactives. 15 octobre 2026 6. Enseignements tirés * **Renforcement de l'isolement de déploiement :** Nous mettons à jour nos procédures de déploiement afin d'assurer une séparation complète des ressources entre les environnements actifs et passifs, en éliminant les conflits entre les ressources environnementales pendant les mises à niveau. * **Optimiser l'allocation des ressources de la base de données :** Pour assurer une performance maximale, nous rééquilibrons notre charge de travail et accroissons la capacité et l'efficacité globales du système. 7. Prochaines étapes et engagement continu Nous nous engageons à : * Résoudre les causes profondes identifiées par les délais partagés * Mettre en place des gardes de sécurité proactifs et des seuils de surveillance, tandis que l'application permanente et l'amélioration de l'infrastructure sont finalisées.

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

1. 2 septembre 2026 à 18:31 UTCidentified

   Notre fournisseur, SSA, a signalé qu'il y a actuellement un problème de latence élevé affectant le module eCBSV. Par conséquent, vous pouvez connaître des temps de réponse élevés. Notre équipe travaille activement avec eux pour résoudre le problème le plus rapidement possible. Nous nous excusons de tout inconvénient que cela peut causer et apprécions votre patience et votre compréhension.

2. 3 septembre 2026 à 15:18 UTCresolved

   SSA a résolu la latence élevée affectant le module eCBSV à partir de 2:00 AM ET. Les temps de réponse sont revenus à la normale. Merci de votre patience et de votre compréhension.

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

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

   Nous étudions une légère dégradation du produit Watchlist en raison de la latence. Affecter à la fois ID+ et RiskOS. L'équipe étudie activement cette question en ce moment.

2. 10 août 2026 à 15:40 UTCidentified

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

3. 10 août 2026 à 15:52 UTCmonitoring

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

4. 10 août 2026 à 16:02 UTCresolved

   This incident has been resolved.

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

1. 4 août 2026 à 07:01 UTCresolved

   Entre 1h21 et 2h15 HAE le 4 août 2026, un sous-ensemble de notifications de livraison en ligne DocV a connu des taux de réponse élevés de 401. Le problème est entièrement résolu et la livraison en ligne fonctionne maintenant normalement. Une analyse complète des causes profondes (ARC) sera partagée une fois l'enquête terminée.

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