Störungsverlauf von Socure

1. 27. Oktober 2026 um 17:08 UTCresolved

   Am 27. Oktober 2026 konnten einige Kunden keine RiskOS Sandbox Webhooks erhalten. Das Problem wurde durch ungültige Webhook-Konfigurationen verursacht, die den Sandbox-Benachrichtigungssender veranlassten, die Verarbeitung von Ereignissen zu stoppen. Die fehlgeformten Konfigurationen wurden seitdem korrigiert. Die gesamte Verarbeitung wurde wiederhergestellt und die Webhook-Lieferung wurde erfolgreich wieder aufgenommen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Oktober 2026 um 21:00 UTCmonitoring

   SSA erlebt derzeit ein dienstrelevantes Ereignis, das mehrere Anwendungen und Dienste betrifft, einschließlich des eCBSV-Dienstes (Electronic Consent Based Social Security Number Verification). Eine kleine Anzahl von Transaktionen ist betroffen, da die Störung erstmals am 23. Oktober 2026 um etwa 4:47 Uhr (ET) festgestellt wurde. Wir werden ein weiteres Update teilen, sobald wir erfahren haben, dass der Dienst wiederhergestellt wurde und eCBSV wieder normal funktioniert.

2. 23. Oktober 2026 um 21:12 UTCresolved

   Um ca. 4:56 Uhr (ET) wurde der Service wiederhergestellt und eCBSV arbeitet derzeit normal. Wir entschuldigen uns für alle Unannehmlichkeiten, die dies verursacht haben könnte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. Oktober 2026 um 19:04 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das eine intermittierende Latenz beim Anzeigen und Herunterladen von DocV-Bildern für einen kleinen Prozentsatz der abgeschlossenen Transaktionen verursacht. Es gibt keine Auswirkungen auf DocV oder Auswertungen zu diesem Zeitpunkt, aber Bilder können zusätzliche Zeit in Anspruch nehmen.

2. 19. Oktober 2026 um 21:15 UTCmonitoring

   Unser Team hat Schritte unternommen, um die Latenzzeit für DocV-Bildanzeige und -Downloads zu verringern. Es gibt weiterhin keine Auswirkungen auf DocV-Bewertungen zu diesem Zeitpunkt und das Team wird die Situation weiterhin überwachen. Wir werden ein weiteres Update bereitstellen, sobald alle Auswirkungen behoben sind.

3. 20. Oktober 2026 um 01:57 UTCresolved

   Dieses Problem wurde behoben, und wir überwachen die Leistung, um sicherzustellen, dass die Dienste stabil bleiben. Wir entschuldigen uns für alle Unannehmlichkeiten, die dies verursacht haben könnte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Oktober 2026 um 19:33 UTCresolved

   SSA erlebte ein Service-Auswirkungen Ereignis, das mehrere Anwendungen und Dienste, einschließlich der Electronic Consent Based Social Security Number Verification (eCBSV) Service betroffen. Eine kleine Anzahl von Transaktionen war betroffen, da die Störung am 18. Oktober 2026 um etwa 2:50 Uhr (ET) begann und um etwa 3:10 Uhr (ET) gelöst wurde. Der Service wurde wiederhergestellt und eCBSV arbeitet derzeit normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Oktober 2026 um 20:20 UTCinvestigating

   Ab 3:00 EDT können bei einigen Kunden intermittierende Fehler oder fehlgeschlagene Anfragen auftreten, wenn sie die RiskOS Evaluate APIs verwenden. Wir haben ein Datenbankproblem identifiziert und arbeiten aktiv daran, es zu beheben. Wir entschuldigen uns für die Störung und schätzen Ihre Geduld, während wir untersuchen.

2. 16. Oktober 2026 um 21:18 UTCmonitoring

   Wir haben eine Übergangsmaßnahme ergriffen und die erhöhte Fehlerquote hat nachgelassen. Wir haben in den letzten 15 Minuten keine verwandten Fehler beobachtet. Wir verlagern den Vorfall auf die Überwachung, während wir weiter an einer vollständigen Auflösung arbeiten. Wir werden ein weiteres Update teilen, wenn sich die Situation ändert.

3. 16. Oktober 2026 um 22:59 UTCmonitoring

   Wir schätzen Ihre Geduld, da unser Team die Situation immer noch genau beobachtet. Die Fehlerquoten haben nachgelassen, da wir weiterhin auf eine vollständige Lösung hinarbeiten.

4. 17. Oktober 2026 um 02:10 UTCresolved

   Der Vorfall wurde behoben, und wir sehen keine Fehler mehr. Die Dienste funktionieren normal und wir werden die Leistung weiterhin überwachen. Wir schätzen Ihre Geduld, während wir das durchgearbeitet haben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Oktober 2026 um 02:23 UTCresolved

   Die Dienste Socure RiskOS und ID+ wurden wiederhergestellt. Ein Fehler in einem Rollout verursachte einen vorübergehenden Anstieg der Fehlerraten unserer Dienste zwischen 18:12 und 18:56 Uhr Ostzeit. Der Fehler wurde korrigiert und die Dienste sind jetzt stabil. Wir verstehen, dass dieser Ausfall inakzeptabel ist und eine vollständige RCA verfügbar ist, sobald die vollständige Analyse des Problems abgeschlossen ist.

2. 17. Oktober 2026 um 01:42 UTCpostmortem

   ## **Wurzelursachenanalyse** **Vorfall:** Socure APIs Ausfall **Datumsbereich:** 15-Oktober-2026 **Auswirkungen:** Unterbrechung im Service für Socure APIs **Status:** Aufgelöst ### **1. Zusammenfassung** Am 15. Oktober 2026, zwischen 18:12 und 19:00 Uhr Eastern Time Socure erlebte eine Unterbrechung seiner RiskOS und ID\ + APIs, was zu Fehlern und Timeouts für die Benutzer. Die erste Phase lief von 18:12 bis 18:20 Uhr und war eine große Unterbrechung für praktisch jeden Dienst. Die zweite Phase des Ausfalls lief von 18:20 bis 19:00 Uhr und war ein teilweiser Ausfall für Dienste, die auf KYC-Daten angewiesen waren, bei denen die Kunden bei einigen Diensten erhöhte Fehlerraten und Latenzen sahen, aber der Datenverkehr immer noch bedient wurde. ### **2. Timeline** **Datum / Uhrzeit \(ET\)** | Event **18:12 | Eine Routine-Bereinigungsänderung wird zusammengeführt und ein Quell-Repo von einem Code-Repository in ein anderes verschoben. Ein Fehler in unserem Review-Tool verbirgt den Umfang der Änderung. **18:13 | ArgoCD startet die meisten Dienste in einem großen Kubernetes-Cluster auf einmal neu. **18:20** | Alle Service-Pods laufen. Der partielle API-Dienst wurde wiederhergestellt, obwohl KYC-Dienste immer noch eine erhöhte Fehlerrate sehen. **18:21** | Die Flut des Startup-Traffics überwältigt unseren KYC-Suchdienst. Fehlerquotenspitze. **18:42** | SRE diagnostiziert den Kaskadierungsfehler, der sich auf die KYC-Suche auswirkt, und blockiert den Datenverkehr, damit er auftauchen kann. **18:56 | Der KYC-Suchdienst ist vollständig aktiviert und SRE gibt den Datenverkehr zurück. Downstream-Dienste stabilisieren sich. **19:00 Uhr | Der gesamte Verkehr läuft normal, der Vorfall wird für stabil erklärt. ### **3. Wurzelursache ** ***Primäre Wurzelursache:** Im Rahmen einer laufenden Migration hat ein On-Call-SRE eine Änderung an ArgoCD vorgenommen, dem System, mit dem wir die Kubernetes-Cluster verwalten, auf dem Socure seine Dienste ausführt. Die Änderung wurde auf einen einzelnen Cluster beschränkt, sorgfältig vor dem Drücken überprüft, verursachte keine Probleme in anderen Umgebungen, in denen sie getestet wurde, und sollte keine sichtbaren Auswirkungen gehabt haben. Leider hat die Änderung eine Legacy-Einstellung aktualisiert, die in der Änderungsüberprüfung nicht angezeigt wurde. Diese Legacy-Einstellung regelte, welche Dienste ArgoCD verwaltete, und entfernte viele Live-Dienste von ArgoCD. Infolgedessen entfernte ArgoCD diese Dienste kurzzeitig aus der Produktion, bevor die Einstellung korrigiert wurde. * **Beitragende Faktoren:** Der KYC-Suchdienst ist ein Backend-Stück der Socure-Infrastruktur, das Dienstleistungen für mehrere unserer internen Produkte bereitstellt. Als dieser Dienst zur gleichen Zeit wie alle Clients des Dienstes von Grund auf neu gestartet wurde, stürzte eine kleine Anzahl von Pods im Dienst unter Last ab. Dies erhöhte die Belastung der verbleibenden Pods, von denen einige wiederum abstürzten. Dieser kaskadierende Fehler verhinderte, dass der Dienst von selbst zurückkehrte, so wie es der Rest der Infrastruktur von Socure tat. Die Diagnose dieses separaten Fehlermodus dauerte zusätzliche Zeit und die Behebung der verbleibenden Fehler nach dem ersten Vorfall. ### **4. Entschließung** Die ArgoCD-Änderung wurde sofort rückgängig gemacht, wodurch die Dienste in ihren vorherigen Zustand zurückkehrten. Der KYC-Suchdienst erforderte manuelle Anstrengungen, um den Datenverkehr zu blockieren, bis eine Mehrheit der Pods im Dienst auftauchen konnte. Nachdem der Service gesund war, konnten wir den Traffic wiederherstellen und den gesamten Vorfall beheben. ### **5. Korrektur- und Präventivmaßnahmen** ### **6. Lektionen gelernt** * Das Tooling von Socure zur Anzeige der Änderungen, die es an der Produktion vornimmt, funktionierte nicht korrekt. Wir überprüfen diese Tools, um sicherzustellen, dass sie unter allen Anwendungsfällen korrekt funktionieren, und beheben Fälle wie diese, in denen der volle Umfang einer Änderung nicht klar ist. * Erweitern Sie den bestehenden Change Review Prozess mit agentischer Unterstützung. Während in diesem Fall die spezifische Änderung im Plan nicht sichtbar war, wird ein zusätzlicher Gutachter, der durch ein umfangreiches Schulungsmodell unterstützt wird, dazu beitragen, dass Probleme vor der Einreichung erfasst werden. * Selbst Änderungen, die keine Auswirkungen zu haben scheinen, wenn sie am Governance-System für unsere Produktionsjobs vorgenommen werden, können riskant sein und sollten weiter aus den US-Geschäftszeiten verschoben werden. * Unser KYC-Suchdienst ist anfällig für ein "Thundering-Herd" -Problem, wenn er den vollen Verkehrsfluss erhält, wenn er nicht vollständig online ist. Wir müssen unsere Leistungsschalter stärken, um zu verhindern, dass sich dieses Problem wiederholt. * Wir betreiben zu viele unserer Kern-API-Dienste in einem einzigen Kubernetes-Cluster. Obwohl dieser Cluster über mehrere Verfügbarkeitszonen verteilt ist, erzeugt die gemeinsame Steuerungsebene einen zu hohen Explosionsradius für Änderungen an diesem Cluster. ### **7. Nächste Schritte & laufendes Engagement** Socure versteht, dass unsere Kunden sich auf uns als Schlüsselanbieter in kritischen Geschäftsströmen verlassen und dass diese Serviceunterbrechung nicht akzeptabel ist. Wir entschuldigen uns für die Auswirkungen, die dieses Problem verursacht hat, und verpflichten uns sicherzustellen, dass es sich nicht wiederholt. Zu diesem Zweck werden wir bis November Details zu unseren Plänen zur Neuarchitektur unseres Anwendungslayouts sowie zur Verbesserung der Widerstandsfähigkeit des KYC-Suchdienstes im ersten Quartal des nächsten Jahres liefern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 23:15 UTCresolved

   Die Dienste Socure RiskOS und ID+ wurden wiederhergestellt. Ein Fehler in einem Rollout verursachte einen vorübergehenden Anstieg der Fehlerraten unserer Dienste zwischen 18:12 und 18:56 Uhr Ostzeit. Der Fehler wurde korrigiert und die Dienste sind jetzt stabil. Wir verstehen, dass dieser Ausfall inakzeptabel ist und eine vollständige RCA verfügbar ist, sobald die vollständige Analyse des Problems abgeschlossen ist.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 22:39 UTCinvestigating

   Wir erleben derzeit einen aktiven Vorfall, der sich auf die Verfügbarkeit des Dienstes auswirkt. Wir untersuchen derzeit das Problem und werden Updates bereitstellen, sobald wir zusätzliche Informationen haben.

2. 15. Oktober 2026 um 23:04 UTCmonitoring

   Die Dienste Socure RiskOS und ID+ wurden wiederhergestellt. Ein Fehler in einem Rollout verursachte einen vorübergehenden Anstieg der Fehlerraten unserer Dienste zwischen 18:20 und 18:56 Uhr Ostzeit. Der Fehler wurde korrigiert und die Dienste sind jetzt stabil. Wir verstehen, dass dieser Ausfall inakzeptabel ist und eine vollständige RCA verfügbar ist, sobald die vollständige Analyse des Problems abgeschlossen ist.

3. 15. Oktober 2026 um 23:04 UTCmonitoring

   Die Dienste Socure RiskOS und ID+ wurden wiederhergestellt. Ein Fehler in einem Rollout verursachte einen vorübergehenden Anstieg der Fehlerraten unserer Dienste zwischen 18:12 und 18:56 Uhr Ostzeit. Der Fehler wurde korrigiert und die Dienste sind jetzt stabil. Wir verstehen, dass dieser Ausfall inakzeptabel ist und eine vollständige RCA verfügbar ist, sobald die vollständige Analyse des Problems abgeschlossen ist.

4. 15. Oktober 2026 um 23:08 UTCresolved

   Die Dienste Socure RiskOS und ID+ wurden wiederhergestellt. Ein Fehler in einem Rollout verursachte einen vorübergehenden Anstieg der Fehlerraten unserer Dienste zwischen 18:12 und 18:56 Uhr Ostzeit. Der Fehler wurde korrigiert und die Dienste sind jetzt stabil. Wir verstehen, dass dieser Ausfall inakzeptabel ist und eine vollständige RCA verfügbar ist, sobald die vollständige Analyse des Problems abgeschlossen ist.

5. 17. Oktober 2026 um 01:30 UTCpostmortem

   ## **Wurzelursachenanalyse** **Vorfall:** Socure APIs Ausfall **Datumsbereich:** 15-Oktober-2026 **Auswirkungen:** Unterbrechung im Service für Socure APIs **Status:** Aufgelöst ### **1. Zusammenfassung** Am 15. Oktober 2026, zwischen 18:12 und 19:00 Uhr Eastern Time Socure erlebte eine Unterbrechung seiner RiskOS und ID\ + APIs, was zu Fehlern und Timeouts für die Benutzer. Die erste Phase lief von 18:12 bis 18:20 Uhr und war eine große Unterbrechung für praktisch jeden Dienst. Die zweite Phase des Ausfalls lief von 18:20 bis 19:00 Uhr und war ein teilweiser Ausfall für Dienste, die auf KYC-Daten angewiesen waren, bei denen die Kunden bei einigen Diensten erhöhte Fehlerraten und Latenzen sahen, aber der Datenverkehr immer noch bedient wurde. ### **2. Timeline** **Datum / Uhrzeit \(ET\)** | Event **18:12 | Eine Routine-Bereinigungsänderung wird zusammengeführt und ein Quell-Repo von einem Code-Repository in ein anderes verschoben. Ein Fehler in unserem Review-Tool verbirgt den Umfang der Änderung. **18:13 | ArgoCD startet die meisten Dienste in einem großen Kubernetes-Cluster auf einmal neu. **18:20** | Alle Service-Pods laufen. Der partielle API-Dienst wurde wiederhergestellt, obwohl KYC-Dienste immer noch eine erhöhte Fehlerrate sehen. **18:21** | Die Flut des Startup-Traffics überwältigt unseren KYC-Suchdienst. Fehlerquotenspitze. **18:42** | SRE diagnostiziert den Kaskadierungsfehler, der sich auf die KYC-Suche auswirkt, und blockiert den Datenverkehr, damit er auftauchen kann. **18:56 | Der KYC-Suchdienst ist vollständig aktiviert und SRE gibt den Datenverkehr zurück. Downstream-Dienste stabilisieren sich. **19:00 Uhr | Der gesamte Verkehr läuft normal, der Vorfall wird für stabil erklärt. ### **3. Wurzelursache ** ***Primäre Wurzelursache:** Im Rahmen einer laufenden Migration hat ein On-Call-SRE eine Änderung an ArgoCD vorgenommen, dem System, mit dem wir die Kubernetes-Cluster verwalten, auf dem Socure seine Dienste ausführt. Die Änderung wurde auf einen einzelnen Cluster beschränkt, sorgfältig vor dem Drücken überprüft, verursachte keine Probleme in anderen Umgebungen, in denen sie getestet wurde, und sollte keine sichtbaren Auswirkungen gehabt haben. Leider hat die Änderung eine Legacy-Einstellung aktualisiert, die in der Änderungsüberprüfung nicht angezeigt wurde. Diese Legacy-Einstellung regelte, welche Dienste ArgoCD verwaltete, und entfernte viele Live-Dienste von ArgoCD. Infolgedessen entfernte ArgoCD diese Dienste kurzzeitig aus der Produktion, bevor die Einstellung korrigiert wurde. * **Beitragende Faktoren:** Der KYC-Suchdienst ist ein Backend-Stück der Socure-Infrastruktur, das Dienstleistungen für mehrere unserer internen Produkte bereitstellt. Als dieser Dienst zur gleichen Zeit wie alle Clients des Dienstes von Grund auf neu gestartet wurde, stürzte eine kleine Anzahl von Pods im Dienst unter Last ab. Dies erhöhte die Belastung der verbleibenden Pods, von denen einige wiederum abstürzten. Dieser kaskadierende Fehler verhinderte, dass der Dienst von selbst zurückkehrte, so wie es der Rest der Infrastruktur von Socure tat. Die Diagnose dieses separaten Fehlermodus dauerte zusätzliche Zeit und die Behebung der verbleibenden Fehler nach dem ersten Vorfall. ### **4. Entschließung** Die ArgoCD-Änderung wurde sofort rückgängig gemacht, wodurch die Dienste in ihren vorherigen Zustand zurückkehrten. Der KYC-Suchdienst erforderte manuelle Anstrengungen, um den Datenverkehr zu blockieren, bis eine Mehrheit der Pods im Dienst auftauchen konnte. Nachdem der Service gesund war, konnten wir den Traffic wiederherstellen und den gesamten Vorfall beheben. ### **5. Korrektur- und Präventivmaßnahmen** ### **6. Lektionen gelernt** * Das Tooling von Socure zur Anzeige der Änderungen, die es an der Produktion vornimmt, funktionierte nicht korrekt. Wir überprüfen diese Tools, um sicherzustellen, dass sie unter allen Anwendungsfällen korrekt funktionieren, und beheben Fälle wie diese, in denen der volle Umfang einer Änderung nicht klar ist. * Erweitern Sie den bestehenden Change Review Prozess mit agentischer Unterstützung. Während in diesem Fall die spezifische Änderung im Plan nicht sichtbar war, wird ein zusätzlicher Gutachter, der durch ein umfangreiches Schulungsmodell unterstützt wird, dazu beitragen, dass Probleme vor der Einreichung erfasst werden. * Selbst Änderungen, die keine Auswirkungen zu haben scheinen, wenn sie am Governance-System für unsere Produktionsjobs vorgenommen werden, können riskant sein und sollten weiter aus den US-Geschäftszeiten verschoben werden. * Unser KYC-Suchdienst ist anfällig für ein "Thundering-Herd" -Problem, wenn er den vollen Verkehrsfluss erhält, wenn er nicht vollständig online ist. Wir müssen unsere Leistungsschalter stärken, um zu verhindern, dass sich dieses Problem wiederholt. * Wir betreiben zu viele unserer Kern-API-Dienste in einem einzigen Kubernetes-Cluster. Obwohl dieser Cluster über mehrere Verfügbarkeitszonen verteilt ist, erzeugt die gemeinsame Steuerungsebene einen zu hohen Explosionsradius für Änderungen an diesem Cluster. ### **7. Nächste Schritte & laufendes Engagement** Socure versteht, dass unsere Kunden sich auf uns als Schlüsselanbieter in kritischen Geschäftsströmen verlassen und dass diese Serviceunterbrechung nicht akzeptabel ist. Wir entschuldigen uns für die Auswirkungen, die dieses Problem verursacht hat, und verpflichten uns sicherzustellen, dass es sich nicht wiederholt. Zu diesem Zweck werden wir bis November Details zu unseren Plänen zur Neuarchitektur unseres Anwendungslayouts sowie zur Verbesserung der Widerstandsfähigkeit des KYC-Suchdienstes im ersten Quartal des nächsten Jahres liefern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 14:52 UTCidentified

   Wir erleben derzeit einen ungeplanten Ausfall des eCBSV-Moduls aufgrund von SSA-Antworten, was zu 5xx-Fehlern führt. Socure hat den Anbieter kontaktiert, um das Problem zu untersuchen und festzustellen, wann der Service voraussichtlich wiederhergestellt wird.

2. 15. Oktober 2026 um 14:55 UTCmonitoring

   Die Fehlerquoten sind in den letzten Minuten gesunken. Wir überwachen diese Preise und warten auf unsere Antwort des Anbieters.

3. 15. Oktober 2026 um 15:59 UTCresolved

   SSA erlebte ein Service-Auswirkungen Ereignis, das mehrere Anwendungen und Dienste, einschließlich der Electronic Consent Based Social Security Number Verification (eCBSV) Service betroffen. Die Störung begann um etwa 10:19 Uhr (ET) am 15. Oktober 2026 und wurde um etwa 10:41 Uhr (ET) gelöst. Der Service wurde wiederhergestellt und eCBSV arbeitet derzeit normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. Oktober 2026 um 23:25 UTCresolved

   Wir haben erhöhte Transaktionsfehler bei Watchlist Plus und Watchlist Premier festgestellt. Das Problem wurde behoben, und wir überwachen die Leistung, um sicherzustellen, dass die Dienste stabil bleiben. Wir entschuldigen uns für alle Unannehmlichkeiten, die dies verursacht haben könnte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. September 2026 um 12:26 UTCidentified

   Wir untersuchen ein Problem, das zu Verzögerungen bei Aktualisierungen führt, die sich in der RiskOS Case Management-Benutzeroberfläche widerspiegeln. Unser Engineering-Team arbeitet aktiv daran, die Ursache zu identifizieren und das normale Update-Verhalten wiederherzustellen. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind. Dies hat keine Auswirkungen auf API-Bewertungsanforderungen.

2. 22. September 2026 um 13:22 UTCmonitoring

   Wir haben die Ursache des Problems identifiziert, das Updates in der RiskOS Case Management-Benutzeroberfläche betrifft. Dieses Problem ist auf eine Teilmenge von Fällen beschränkt und wirkt sich speziell auf die Fallsuche-Funktionalität aus, die vorübergehend veraltete Fallzustände anzeigen kann. Bitte beachten Sie, dass die in der Fallliste und den einzelnen Falldetailseiten angezeigten Fallstatusdaten korrekt sind und den neuesten Zustand widerspiegeln. Unser Engineering-Team hat einen Fix für alle neu aktualisierten Fälle bereitgestellt und arbeitet aktiv daran, die verbleibenden betroffenen Fälle neu zu synchronisieren, um die Datenkonsistenz bei der Suche sicherzustellen. Wir werden ein weiteres Update bereitstellen, sobald das normale Verhalten vollständig wiederhergestellt ist.

3. 22. September 2026 um 14:09 UTCresolved

   Das Problem mit der Aktualisierung des Fallstatus wurde behoben. Alle neuen Fälle werden korrekt bearbeitet. Wir entschuldigen uns aufrichtig für alle Unannehmlichkeiten, die dies verursacht haben könnte, und schätzen Ihre Geduld, während unser Team daran arbeitete, sie zu lösen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 11:57 UTCresolved

   Zwischen 6:28 Uhr und 6:57 Uhr ET am 21. September führte ein Problem während einer operativen Aktivität dazu, dass einige Webhook-Benachrichtigungen im Zusammenhang mit älteren Bewertungen des letzten Monats erneut geliefert wurden. Aktuelle Auswertungen und Webhook-Verarbeitung waren nicht betroffen. Das Problem ist gelöst. Wir entschuldigen uns für jegliche Verwirrung oder zusätzlichen Lärm, den dies verursacht haben könnte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 14:36 UTCinvestigating

   Wir untersuchen Verzögerungen bei der Batch-Verarbeitung auf dem Dashboard. Kunden können eine verzögerte Verarbeitung erfahren, während wir das Problem überprüfen.

2. 16. September 2026 um 14:49 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. September 2026 um 09:39 UTCidentified

   Wir beobachten eine erhöhte Latenz, die einige Kunden betrifft, die unsere Betrugs- und Synthetikprodukte verwenden. Unser Team untersucht das Problem aktiv. API-Anfragen werden erfolgreich abgeschlossen, und wir beobachten derzeit keine API-Ausfälle. Wir werden weitere Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 16. September 2026 um 10:07 UTCmonitoring

   Wir sehen eine Verbesserung der Latenz, die einige Kunden betrifft, die unsere Betrugs- und Synthetikprodukte verwenden. Wir werden die Situation weiterhin genau beobachten.

3. 16. September 2026 um 10:12 UTCresolved

   Das Problem, das sich auf Betrugs- und Synthetikdienste auswirkt, wurde behoben, und der Dienst ist in den normalen Betrieb zurückgekehrt. Kunden sollten keine erhöhten Latenzzeiten oder Verzögerungen mehr erleben, wenn sie auf Betrugs- und Synthetikdienste zugreifen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. September 2026 um 19:39 UTCresolved

   Zwischen 8:30 Uhr und 14:00 Uhr EST beobachteten wir einen Anstieg der Fehlerquoten von 5xx, was bei einigen Kunden zu intermittierenden Fehlern oder fehlgeschlagenen Anfragen führte. Die Gesamtwirkung war minimal, weniger als 0,01%. Die Fehlerquote ist seitdem wieder normal. Dieses Problem ist zum jetzigen Zeitpunkt vollständig gelöst. Wir entschuldigen uns für jede Störung und schätzen Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 9. September 2026 um 11:37 UTCresolved

   Zwischen 7:00 Uhr und 7:20 Uhr EST beobachteten wir einen Anstieg der Fehlerquoten von 5xx, was bei einigen Kunden zu intermittierenden Fehlern oder fehlgeschlagenen Anfragen geführt haben kann. Die Fehlerquote hat sich seitdem wieder normalisiert, und wir untersuchen die Ursache, um sicherzustellen, dass wir das Problem vollständig gelöst haben. Wir entschuldigen uns für jede Störung und schätzen Ihre Geduld.

2. 15. September 2026 um 18:15 UTCpostmortem

   ** Wurzelursachenanalyse** **Vorfall:** Intermittierend erhöhte 5xx Fehler über Dienste hinweg **Datumsbereich: ** 9. September 2026, 7:00 Uhr – 9:20 Uhr EDT \(ca. 2 Stunden 20 Minuten intermittierender Aufprall\) **Auswirkungen:** Einige Anfragen, die an die EmailAuthScore-API und verwandte Dienste übermittelt wurden, gaben zeitweise Fehlerantworten zurück. Die Auswirkungen waren eher intermittierend als kontinuierlich und beschränkten sich auf definierte Fenster, die in der folgenden Zeitleiste beschrieben wurden. **Status:** Aufgelöst ### **1. Zusammenfassung** Am 9. September 2026 führte eine geplante Erhöhung der Backend-Verarbeitungskapazität zu einer erhöhten Verbindungsbelastung einer internen Infrastrukturkomponente, die zur Unterstützung der nachgelagerten Verarbeitung für mehrere Dienste verwendet wurde. Diese Komponente erreichte einen internen Kapazitätsschwellenwert, der Verarbeitungsverzögerungen einführte und zu intermittierenden Fehlerreaktionen auf der EmailAuthScore-API und verwandten Diensten für eine Teilmenge von Anfragen führte. Das Problem wurde durch eine Kombination aus interner Überwachung und Berichten während des Aufprallfensters identifiziert. Socure Engineering korrelierte die Fehler mit der jüngsten Kapazitätsänderung und kehrte sie um, was den anfänglichen Anstieg der Fehler stoppte. Eine zweite, damit verbundene Zunahme von Fehlern trat dann auf, wenn eine separate Kapazitätsänderung, die früher für einen anderen internen Dienst vorgenommen wurde, die gleiche gemeinsame Komponente zusätzlich belastete. In Abschnitt 5 werden die Korrektur- und Vorbeugungsmaßnahmen beschrieben, zu denen sich Socure verpflichtet, wobei die Transparenz der Infrastrukturkapazität zu verbessern und zu verhindern ist, dass Verzögerungen bei einer einzelnen internen Komponente die Bearbeitung von Kundenanfragen beeinträchtigen. ### **2. Timeline** | **Datum / Uhrzeit \(EDT\)** | **Event** | | --- | --- | **September 9, 2026 07:00 Uhr ** | Nach einer geplanten Erhöhung der Backend-Verarbeitungskapazität begann die EmailAuthScore-API, intermittierend Fehlerantworten zurückzugeben. | | **September 9, 2026 07:20 Uhr** Die jüngste Kapazitätsänderung wurde rückgängig gemacht; die Fehlerquoten wurden wieder normal. | **9. September 2026 08:45 Uhr | Eine separate Kapazitätsänderung, die zuvor für einen anderen internen Dienst vorgenommen wurde, belastete die gleiche freigegebene interne Komponente zusätzlich und die EmailAuthScore-API begann erneut, intermittierend Fehlerantworten zurückzugeben. | | **September 9, 2026 09:20 Uhr ** | Zusätzliche Abschwächungen wurden angewendet; die Fehlerquoten wurden wieder normal und blieben stabil. | | **September 9, 2026 01:13 Uhr ** | Vorsorglich leitete Socure einen Teil der internen Verarbeitung vorübergehend von der betroffenen internen Komponente weg, um die verbleibende Kapazitätserhöhung sicher abzuschließen. Nach dieser Änderung wurden keine weiteren Fehler beobachtet. | ### **3. Wurzelursache ** ***Primäre Wurzelursache:** Im Rahmen der geplanten Arbeiten zur Erhöhung der Systemkapazität vor der erwarteten Nachfrage erhöhte Socure die Verarbeitungskapazität von Backend-Services. Diese Änderung erhöhte die Anzahl der Verbindungen zu einer internen Messaging-Komponente, die zur Unterstützung der nachgelagerten Verarbeitung für diese Dienste verwendet wird. Diese Komponente erreichte eine interne Verbindungskapazitätsgrenze, was zu Verbindungs- und Verarbeitungsverzögerungen führte. Diese Verzögerungen führten zu einer zusätzlichen Latenz und in einigen Fällen zu einem Rückdruck bei der Anforderungsverarbeitung, was zu intermittierenden erhöhten Fehlerraten bei der E-MailAuthScore-API und verwandten Diensten für eine Teilmenge von Anfragen während der oben beschriebenen Aufprallfenster beitrug. * **Beitragende Faktoren:** * Ein plötzlicher Anstieg der Nachfrage nach Infrastrukturkapazitäten überstieg die Kapazität, die in der internen Messaging-Komponente sofort nicht verfügbar war. ### **4. Entschließung** Nachdem festgestellt wurde, dass die erhöhten Fehlerraten mit der jüngsten Kapazitätsänderung verknüpft waren, kehrte Socure Engineering die Änderung zurück, was den anfänglichen Anstieg der Fehler stoppte. Eine zweite, damit verbundene Zunahme von Fehlern trat dann auf, wenn eine separate Kapazitätsänderung, die früher für einen anderen internen Dienst vorgenommen wurde, die gleiche gemeinsame Komponente zusätzlich belastete. Engineering hat zusätzliche Maßnahmen ergriffen, einschließlich der vorübergehenden Umleitung eines Teils der internen Verarbeitung von der betroffenen Komponente für die betroffenen Dienste. Nach diesen Aktionen kehrten alle betroffenen Dienste zu einem normalen, stabilen Betrieb zurück, was Socure durch eine kontinuierliche Überwachung bestätigte. ### **5. Korrektur- und Präventivmaßnahmen** | **Aktion** | **Beschreibung** | **ETA / Status** | | --- | --- | Optimierung der Kapazitätsauslastung der Infrastruktur | Angepasste Backend-Service-Kapazität und Verbindungsauslastung, um sicherzustellen, dass die Verarbeitung innerhalb der unterstützten Infrastrukturgrenzen bleibt und das Risiko ähnlicher kapazitätsbezogener Probleme reduziert wird. | Erledigt | | Erhöhung der Kapazität der Messaging-Infrastruktur | Erhöht die Kapazität der zugrunde liegenden Messaging-Infrastruktur, um zusätzlichen Spielraum zu schaffen und zukünftige Steigerungen des Verkehrsaufkommens zu unterstützen. | Erledigt | | Verbesserung der Kapazitätsüberwachung und Alarmierung | Hinzufügen proaktiver Überwachung und Warnungen, um potenzielle Infrastrukturkapazitätsbeschränkungen zu identifizieren, bevor sie die Serviceleistung beeinträchtigen. | Im Gange. ETA 30 Sep 2026. | ### **6. Lektionen gelernt** * Eine proaktive Überwachung des Infrastrukturzustands muss vor Kapazitätsänderungen vorhanden sein, nicht nur auf Anwendungsebene. ### **7. Nächste Schritte & laufendes Engagement** Wir verpflichten uns: * Abschluss der in Abschnitt 5 aufgeführten Korrektur- und Vorbeugungsmaßnahmen. * Verbesserung der Sichtbarkeit des Zustands und der Kapazität kritischer interner Infrastruktur vor zukünftigen Skalierungsaktivitäten. * Bereitstellung eines Folge-Updates, sobald alle Korrekturmaßnahmen abgeschlossen sind.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. September 2026 um 14:54 UTCinvestigating

   Wir untersuchen derzeit ein Problem, das sich auf die Überwachungsdienste von DocV und Watchlist ausgewirkt hat, bei denen heute, am 8. September, von 09:05 Uhr EST bis 09:30 Uhr EST Fehler beobachtet wurden. Das System hat sich erholt, wir arbeiten derzeit daran, eine Ursache zu ermitteln.

2. 8. September 2026 um 15:41 UTCresolved

   Das Problem, das DocV- und Watchlist-Überwachungsdienste am 8. September betrifft, wurde behoben. Seit 10:35 Uhr EST wurden keine Kundenauswirkungen mehr beobachtet. Wir entschuldigen uns für jede Störung, die dies verursacht haben könnte.

3. 17. September 2026 um 19:47 UTCpostmortem

   **Wurzelursachenanalyse** **Vorfall:** Dienstunterbrechung, die den Zugang zu Kontodaten beeinflusst **Datumsbereich:** 8. September 2026 \(10:04 Uhr bis 10:31 Uhr EDT\) **Impact:** DocV und Watchlist Monitore **Status:** Aufgelöst ###1 Zusammenfassung Eine unerwartete Erschöpfung der Backend-Datenbankkapazität verhinderte vorübergehend, dass unsere Plattform Kontoinformationen für eine Teilmenge von Kundenanfragen abrufen konnte. Während des Incident-Fensters (10:04 Uhr bis 10:31 Uhr EDT von 8-Sep-2026) hatten einige Client-Anfragen erhöhte Fehlerraten, wenn sie versuchten, Kontodaten abzufragen. Nach einem routinemäßigen Wartungsupdate überschritten gleichzeitige Verbindungen aus Backup-Umgebungen die normalen Schwellenwerte und sättigten die verfügbare Datenbankkapazität. Engineering-Teams trennten die redundanten Umgebungen sicher und aktualisierten aktive Verbindungen, wodurch die Reaktionsfähigkeit und Stabilität des Systems wiederhergestellt wurde. ###2 Timeline | **Datum / Uhrzeit \(ET\)** | **Event** | | --- | --- | Erster Fehler | 10:04 Uhr EST, 8 Sep 2026 | | Vorfall berichtet | 10:17 Uhr EST, 8 Sep 2026 | | Redundanter Umgebungsanschlusspool isoliert | 10:30 Uhr EST, 8 Sep 2026 | | Vorfall gelöst | 10:31 Uhr EST, 8 Sep 2026 | ### 3. Wurzelursache ***Primäre Wurzelursache:** Während eines geplanten Systemupdates führte eine erhöhte Verbindungsbindung zwischen Bereitstellungsumgebungen zu einer Sättigung des Datenbankverbindungspools. Bei hohem Traffic verursachte dies Verarbeitungsverzögerungen und Anforderungs-Timeouts für abhängige Plattformdienste. * **Beitragende Faktoren:** * Starre Verbindungs-Timeout-Parameter verzögerten die zeitnahe Freigabe von untätigen Datenbankzuweisungen durch passive Umgebung. * Eine unzureichende Datenbankknoten-Headroom verhinderte die nahtlose Verarbeitung zusätzlicher Verbindungen, die durch die Standby-Umgebung erzeugt wurden. * **Nicht beitragende Faktoren:** * Keine ### 4. Resolution Die volle Service-Integrität wurde durch folgende Sofortmaßnahmen wiederhergestellt: 1. Isolierung nicht aktiver Umgebungsverbindungen auf sofort freie Datenbankpoolkapazität. 2. Durchführung eines Roll-Resets aktiver Dienstknoten zur Wiederherstellung klarer Datenbankverbindungsbasislinien. ### 5. Korrektur- und Präventivmaßnahmen | **Aktion** | **Beschreibung** | **ETA / Status** | | --- | --- Verbesserungen bei Datenzugriffsmustern Verbessern Sie die Caching-Strategie und Datenzugriffsmuster in internen Diensten, die auf Kontodaten basieren. | 15 Okt 2026 | | Automatisiertes Verbindungsmanagement | Verbesserung des Verbindungslebenszyklusmanagements und automatisierter Bereinigungsroutinen für inaktive Hintergrundaufgaben. | 15 Okt 2026 | ### 6. Lektionen gelernt * **Verbesserung der Deployment Isolation:** Wir aktualisieren unsere Bereitstellungsverfahren, um eine vollständige Trennung der Ressourcen zwischen aktiven und passiven Umgebungen zu gewährleisten und um den umgebungsübergreifenden Ressourcenkonflikt bei Upgrades zu beseitigen. * **Optimierung der Datenbankressourcenzuweisung:** Um eine Spitzenleistung zu gewährleisten, balancieren wir unsere Arbeitsbelastung und erhöhen die Gesamtsystemkapazität und -effizienz. ### 7. Nächste Schritte und laufendes Engagement Wir verpflichten uns: * Beheben Sie die identifizierten Ursachen durch die gemeinsam genutzten Zeitlinien Implementieren Sie proaktive Sicherheitsvorkehrungen und Überwachungsschwellen, während permanente Anwendungs- und Infrastrukturverbesserungen abgeschlossen sind.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. September 2026 um 18:31 UTCidentified

   Unser Anbieter, SSA, hat berichtet, dass es derzeit ein erhöhtes Latenzproblem gibt, das das eCBSV-Modul betrifft. Infolgedessen können Sie erhöhte Reaktionszeiten erleben. Unser Team arbeitet aktiv mit ihnen zusammen, um das Problem so schnell wie möglich zu lösen. Wir entschuldigen uns für alle Unannehmlichkeiten, die dies verursachen kann, und schätzen Ihre Geduld und Ihr Verständnis.

2. 3. September 2026 um 15:18 UTCresolved

   SSA hat die erhöhte Latenz des eCBSV-Moduls ab 2:00 Uhr ET behoben. Die Reaktionszeiten sind wieder normal. Vielen Dank für Ihre Geduld und Ihr Verständnis.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. August 2026 um 15:40 UTCinvestigating

   We are investigating a slight degradation on the Watchlist product due to latency. Affecting both ID+ and RiskOS. The team is actively investigating this issue at this time.

2. 10. August 2026 um 15:40 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 10. August 2026 um 15:52 UTCmonitoring

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

4. 10. August 2026 um 16:02 UTCresolved

   This incident has been resolved.

1. 4. August 2026 um 07:01 UTCresolved

   Between 1:21 AM and 2:15 AM EDT on August 4, 2026, a subset of DocV webhook delivery notifications experienced elevated 401 response rates. The issue is fully resolved and webhook delivery is now operating normally. A full Root Cause Analysis (RCA) will be shared once the investigation concludes.