61 Onfido incidents · Mai 2025 — official updates, affected components, duration and resolution details.
Wir können derzeit keine eVisa-Berichte und -Aufgaben für Großbritannien ausfüllen, da unser Anbieter ausfällt.
Die Dienste des Anbieters wurden wiederhergestellt, unsere eVisas-Aufgaben in Großbritannien sind wieder abgeschlossen.
Unsere Dienste sind wieder in Betrieb.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Einer unserer Anbieter hat Probleme, die zu Verzögerungen bei einigen Berichten führen. Wir untersuchen das Problem.
Unser Anbieter hat immer noch Probleme. Wir beobachten die Situation genau. ID-UK ist unser am stärksten betroffener Service.
Der Anbieter ist sich des Problems bewusst. Wir sind immer noch bereit, unsere Dienste wieder aufzunehmen, sobald das Problem gelöst ist.
Unser Anbieter ist von einem großen globalen Vorfall bei einem seiner Anbieter betroffen, an dem aktiv gearbeitet wird.
Fehler gestoppt. Wir überwachen unsere Dienste, um sicherzustellen, dass alles wieder normal ist.
Unsere Dienste sind wieder in Betrieb.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben Probleme mit unseren Anbietern und sehen, dass Identitätsberichte nicht in der britischen Gerichtsbarkeit verarbeitet werden
Das Problem wurde identifiziert und wir haben einen Workaround angewendet
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
Wir werden weiterhin auf weitere Probleme achten.
Dieser Vorfall wurde behoben
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Dieser britische Regierungsdienst ist derzeit nicht verfügbar. Wir überwachen die Situation, bis der Service wieder online ist.
Wir arbeiten weiter an einer Lösung für dieses Problem.
3rd-party-anbieter scheint jetzt wieder online zu sein. Schecks werden bearbeitet. Fortsetzung der Überwachung der Situation.
3rd-party-anbieter ist wieder online. Schecks, die zuvor stecken geblieben sind, wurden jetzt verarbeitet.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Zwischen 14:30 und 15:30 UTC erlebten Kunden in der CA-Region einen eingeschränkten Zugriff auf die Public API. Eine fehlerhafte Bereitstellung in der Authentifizierungsschicht führte dazu, dass gültige Token falsch abgelehnt wurden, was zu fehlgeschlagenen API-Anforderungen führte. Das Problem ist vollständig gelöst. Es ist keine Aktion an Ihrem Ende erforderlich. Wir entschuldigen uns für die Störung.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Von etwa 1:21 Uhr UTC bis 1:46 Uhr UTC gab es eine Störung bei der Annahme von Dokumentenanforderungen vom Web SDK sowie von Entrust IDV SDKs für Flüsse, die Webmodule enthalten. Onfido Android & iOS SDKs waren nicht betroffen. Wir entschuldigen uns für diese Störung. Ein detailliertes Postmortem wird folgen, sobald wir unsere Untersuchung abgeschlossen haben.
### Zusammenfassung Am 1. September 2026, von 13:21 UTC bis 13:45 UTC, konnten Benutzer, die versuchten, Dokumente im Web SDK zu erfassen, ihre Sitzung nicht beenden. Dies wurde auch auf native Entrust IDV SDKs für Konfigurationen erweitert, die Webmodule enthalten. Native Onfido Android und iOS SDKs waren nicht betroffen. ### Wurzelursachen Eine routinemäßige Aktualisierung eines Container-Images für unseren Dokumentkonfigurationsdienst führte zu einer Regression des Synchronisierungsauftrags, der die Dokumentenliste aktualisiert. Dies führte zu dem Endpunkt, den unsere SDKs verwenden, um Dokumente abzurufen, die "500" -Fehler zurückgeben. Dies verhinderte, dass Web-SDK-Flows weitergingen. Unsere nativen SDKs verwenden eine Backup-Dokumentenliste, die es ihnen ermöglichte, normal fortzufahren. Unsere progressiven Rollouts sind darauf ausgelegt, Servicefehler zu erkennen, bevor sie signifikant werden. Der Synchronisationsfehler markierte die Bereitschaftssonde jedoch nicht als ungesund, so dass der Rollout fortgesetzt wurde. ### Timeline 13:10 UTC: Wir haben einen progressiven Rollout der Änderung gestartet. 13:21 UTC : Der Service wurde vollständig ausgerollt, was zu Fehlern bei der betroffenen SDK-Funktionalität führte. 13:26 UTC: Monitoring alarmierte das Team. 13:44 UTC: Ursache identifiziert und Änderung zurückgerollt. 13:45 UTC: Service wiederhergestellt. ### Heilmittel * Wir werden fehlende automatisierte Testabdeckung hinzufügen, um sicherzustellen, dass wir diese Fälle in Zukunft erfassen. * Wir fügen dem Web-SDK eine Fallback-Dokumentliste hinzu, die dem in den nativen SDKs vorhandenen Mechanismus ähnelt, um sicherzustellen, dass er im Falle ähnlicher zukünftiger Fehler weiterhin funktionieren kann. * Wir werden den progressiven Rollout beheben, um sicherzustellen, dass der Rollout nicht fortgesetzt wird, falls beim Synchronisieren von Dokumenten etwas schief gelaufen ist.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Bekannte Gesichter, die höhere Preise in allen Regionen erleben.
## Zusammenfassung Am 26. August 2026 wurde im Zeitraum zwischen 15:00 und 18:00 UTC ein Anstieg der Berücksichtigungsrate für bekannte Gesichter beobachtet. Die insgesamt beobachtete Rate der bekannten Gesichter stieg in allen Regionen von ~ 6% auf ~ 23%. Der wahrgenommene Anstieg kann höher oder niedriger gewesen sein, abhängig von der spezifischen Geographie des Kunden oder der Vertikalen. Der Grund dafür war eine Änderung der Berechnung von Matching-Scores für Known Faces-Matches, die die Ergebnisse für nicht übereinstimmende Gesichter aufblähte und so dazu führte, dass viele Berichte falsche Matches und ein **consider**-Ergebnis zurückgaben. ## Wurzelursachen Die Änderung führte einen neuen Algorithmus für die Bewertung von übereinstimmenden Gesichtern ein, der die Erinnerungsleistung von Known Faces verbessern soll. Dies wurde umfassend durch interne Benchmarks bewertet und validiert, bevor es veröffentlicht wurde. Der Übergang von Benchmarks zur Produktion berücksichtigte versehentlich teilweise keine besonderen Eigenschaften der Produktionsumgebung. An der Wurzel wurde eine einzelne Konstante im Übergang nicht richtig konvertiert, was zu einem falschen Verhalten des neuen Scoring-Algorithmus führte. ## Timeline 15:20 UTC: Change to Known Faces wird veröffentlicht 17:35 UTC: Erhöhte Berücksichtigungsrate auf Known Faces wird bemerkt. 17:50 UTC: Der Wechsel wird zurückgenommen. Betrachten Sie die Rate fällt bald danach. ## Heilmittel Wir überprüfen interne Benchmarks und Testverfahren, die die Sicherheit solcher Veränderungen erhöhen können. Insbesondere spiegelt die Sicherstellung interner Tests die reale Produktionslandschaft wider, wenn es um Datensätze geht, und dass Übergänge von internen Benchmarks und Experimenten zur Produktion gründlich getestet werden. Darüber hinaus werden Änderungsverfahren mit einer strengeren Überwachung durchgeführt, so dass wir schneller bemerken und handeln können.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Bewegungsüberprüfungen mit Zufälligkeitsherausforderungen scheitern viel häufiger als normal in der EU-Region.
## Zusammenfassung Am 24. August 2026, zwischen 15:00 UTC und 06:53 UTC am nächsten Morgen, scheiterten Gesichtsähnlichkeits-Bewegungsüberprüfungen mit Zufälligkeitsherausforderungen mit einer viel höheren Rate als normal in der EU-Region. Eine strengere Validierung wurde für alle Kunden in der Region angewandt, obwohl sie auf einen einzigen Kunden hätte beschränkt werden sollen, was dazu führte, dass Überprüfungen, die ansonsten bestanden hätten, abgelehnt wurden. Betroffene Berichte wurden mit einem "Visual Authenticity" -Fehler zurückgegeben. Da Motion-Checks vollständig automatisiert sind, wurden die Endbenutzer hinter diesen Berichten ohne manuelle Überprüfung abgelehnt, und einige versuchten die Überprüfung erneut und wurden ein zweites Mal abgelehnt. Die klare Rate für diese Kontrollen fiel von rund 97% auf rund 54% für etwa 1,67 % der Gesichtsähnlichkeit Motion Berichte betroffen waren. Durch Deaktivieren der Änderung wurden die normalen Clear-Raten sofort wiederhergestellt. Andere Motion Checks und andere Regionen waren nicht betroffen. ## Wurzelursachen Eine strengere Validierung der Motion-Zufälligkeitsherausforderung wurde mit einem einzigen Kunden getestet, der von einer Konfigurationseinstellung pro Kunde kontrolliert wurde. Ein Fehler in unserem Code bedeutete, dass die Einstellung ohne die Kundenkennung ausgewertet wurde, so dass die strengere Validierung auf alle Kunden in der EU-Region angewendet wurde, die Motion mit Zufallsprüfungen ausführen, anstatt auf den beabsichtigten. Überprüfungen, die unter der Standardvalidierung bestanden hätten, wurden stattdessen abgelehnt und unter der Aufschlüsselung "Visual Authenticity" gemeldet. Keine kundenkonfiguration oder eingereichte daten waren fehlerhaft. ## Timeline Alle Zeiten UTC. * 24. August, 15:00 Uhr: Wir haben eine strengere Validierung für Herausforderungen bei Bewegungszufälligkeit in der EU-Region ermöglicht. Motion Checks mit Zufälligkeit begann mit einer viel höheren Rate zu scheitern. * 24. August, 16:36: Ein Kunde meldete einen Rückgang der Workflow-Erfolgsraten und wir begannen zu untersuchen. * 25. August, 04:18: Wir haben die erhöhte Ausfallrate bestätigt und eskaliert. * 25. August, 06:53: Wir haben die Änderung rückgängig gemacht und die klaren Preise innerhalb von Minuten wieder normalisiert. * 26. August: Wir haben eine dauerhafte Reparatur durchgeführt. ## Heilmittel * Verbessern Sie die Kontrollen für kundenspezifische Konfigurationsänderungen, um sicherzustellen, dass sie nicht breiter als vorgesehen angewendet werden können. * Verbessern Sie die Überwachung und Alarmierung auf zufällige Geschwindigkeitsprüfungen, damit unerwartete Änderungen der Ablehnungsraten automatisch erkannt und schneller eskaliert werden.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit Verzögerungen in unserem US-Cluster für die Verarbeitung von Gesichtsähnlichkeit, Dokumenten und bekannten Gesichtern.
Wir sehen eine verminderte Leistung einiger Knoten in unserem Suchcluster für indizierte Gesichter. Wir untersuchen weiterhin die Ursache und mögliche Abhilfemaßnahmen.
Wir haben die Hauptursache für verminderte Leistung in unserem US-Suchcluster identifiziert und arbeiten aktiv daran, sie zu beheben. Wir werden nachgehen, wenn wir vollständig wiederhergestellt sind.
Wir haben einen Fix implementiert und überwachen weiterhin die Qualität der Verarbeitungszeit, die jetzt verbessert wird.
Die Verarbeitungszeit verbessert sich ständig, alle Systeme sind jetzt in Betrieb.
Die Bearbeitungszeiten sind wieder normal. Dieses Problem ist nun gelöst. Post-mortem folgt bald.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Identity Enhanced erlebt einen starken Rückgang der klaren Preise für Bewerber in der ganzen Welt außer Großbritannien
Wir arbeiten mit unserem Drittanbieter zusammen, um das Problem zu beheben, und werden Updates teilen, sobald sie verfügbar sind.
Wir arbeiten weiter an einer Lösung für dieses Problem.
Wir sehen, wie sich die Servicewiederherstellung unseres Anbieters verbessert und die Erfolgsraten verbessert werden. Wir verfolgen die Situation weiterhin aufmerksam.
Der Anbieter hat das Problem behoben und der Dienst funktioniert jetzt normal
Automatisch aus der offiziellen Störungsmeldung übersetzt.
We cannot complete QES tasks because our electronic signature provider is encountering issues.
Our provider is experiencing issues. All QES tasks cannot complete for now.
Our provider is still experiencing issues. All QES tasks cannot complete for now.
The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.
This incident has been resolved.
We're currently monitoring the EU cluster after an Amazon RDS issue.
We’re seeing recovery across our internal metrics, and processing has now returned to full capacity. At this time, the issue appears to be resolved. Our current leading hypothesis is resource contention on a shared Amazon RDS instance that several services depend on, potentially related to a VACUUM operation running alongside a long-running job deleting a large volume of accumulated historical data. We have not yet confirmed the root cause and will continue investigating as follow-up, but service has been restored for now. We'll be following up with a public post-mortem.
**Incident date:** 22 June 2026 **Region:** EU \(eu-west-1\) **Affected EU services**: API, Dashboard, Applicant Form, Document Verification, Facial Similarity, Watchlist, Identity Enhanced, Webhooks, Known Faces, Autofill, QES and Device Intelligence. **Customer impact:** ~16:50–17:00 UTC \(acute degradation\); ~17:00–17:20 UTC \(backlog recovery\) ## Summary On 22 June 2026, from approximately 16:50 UTC, a shared database cluster serving our EU region came under severe load and could not reliably serve queries for about 10 minutes. EU services returned elevated errors, and processing throughput briefly fell to ~20–35% of normal levels, with many subcomponents of our system \(e.g., Facial Similarity report processing\) being entirely disrupted, some others less heavily impacted \(e.g., Document report processing\). Service recovered by 17:01 UTC, the database fully stabilizing after an automatic failover \(~17:05–17:07 UTC\). A resultant report backlog was cleared by ~17:20 UTC. Requests in flight during the acute degradation window may have failed unless retried; queued background work was processed automatically once the database recovered. ## Root cause The incident was triggered by a routine database storage-reclamation task following standard scheduled data-deletion processing. This task normally completes without issue; why it failed on this occasion remains under investigation, although we observed that it was processing a larger-than-usual backlog. We have a support case open with our cloud provider to confirm a definitive root cause. The reclamation task began to compete with normal application queries, which slowed as the database struggled to keep up. Applications opened more and more connections, leading to connection saturation and causing queries across the affected services to fail. The database stabilized when an automatic failover to a healthy standby was triggered; the contention fully resolving with the failover to a new instance. ## Timeline \(UTC\) * **16:50** — Our monitoring detected errors and elevated latency across EU services caused by resource contention on a shared database cluster. * **16:53** — We start to see improvements, but system still not acting at normal levels of performance. * **~17:00** — Customer-facing errors subsided and processing resumed as the contention eased. * **17:01** — On-call engineers opened an incident and continued investigations. * **~17:05–17:07** — The database performed an automatic failover to a healthy instance, which reset the overloaded writer and fully stabilised the cluster. The failover was triggered because of resource contention \(out of memory\) caused by the heavy vacuuming in the preceding minutes of the incident. Once the impacting vacuum operations had finished freeing up resources, we had started to see signs of improvement \(16:53—17:01\), but added latency in the feedback loop and aggregation window at AWS still decided to trigger the failover, even though we were already in a recovering state. * **17:15–17:20** — Requests that had queued during the incident were worked through and the backlog returned to normal. * **17:21–17:56** — We monitored the recovery and confirmed processing remained at full capacity. ## Remedies * Reviewing connection limits and pooling so a single service cannot saturate a shared database, and evaluating dedicated database clusters per product to remove cross-service impact. * Changing large historical-data deletions to run in smaller, throttled batches, and tuning database maintenance to avoid large catch-up operations. * Adding earlier, proactive alerting on database memory, connections and load so we can intervene before customer impact. * Continue working with our cloud provider on a definitive root cause.
One of our providers is still experiencing issues, resulting in higher TaT for electronic signature tasks.
Our provider is actively working on fixing the issue.
Our provider is still working on fixing the issue. We're monitoring the impact and we're making sure to keep the TaT as low as possible, considering the situation.
Our provider's error rate dropped significantly. The TaT of QES tasks is now close to the usual value.
We're working closely with our provider to find the reason of the remaining errors. The error rate contacting our provider is stable and the impact on the QES task TaT is under control.
Our provider was able to fix the issue and we don't get any error when contacting them. The TaT of QES tasks is back to normal. Monitoring the situation to make sure the errors don't come back.
The QES tasks TaT is back to normal.
Our electronic signature tasks are taking more time to complete because one of our providers is doing some maintenance.
Our provider is still not able to answer to all requests, resulting in longer-than-usual electronic signature task processing time.
The service is operational again.
Incident was solved.
## Summary Between May and June 2026, around 0.037% of the evidence files generated on the platform were incomplete and included in the corresponding evidence folders. There was no impact on workflow results, and no incorrect information was ever displayed — the affected files were simply empty rather than wrong. A small number of requests to generate timeline files were also affected \(around 0.073%\). ## Root Causes The issue was introduced during an initiative to improve how timeline and evidence PDFs are generated — making them significantly smaller, more efficient, and more resilient to produce. As part of these changes, in rare cases the new flow attempted to generate the PDF before its content had fully loaded, resulting in a blank or nearly empty file. Because the problem was intermittent and occurred only in rare timing conditions, it was not consistently reproduced during rollout testing. ## Timeline * 15 June 2026: Engineering investigation found an incomplete PDF and started the root cause investigation * 17 June 2026: Root cause investigation completed and a safeguard to prevent incomplete PDFs was deployed ## Remedies * We corrected the PDF generation flow so PDFs are only printed after content has fully loaded, and added a safeguard that stops generation when an incomplete PDF is detected. * We also improved our monitoring and test coverage for PDF generation, so similar issues are caught earlier in the future.
Some Watchlist search search profiles are not working correctly the impacted reports are not being processed. We are investigation the root cause.
We identified the issue and are implementing a fix.
The issue has been fixed, and the reports are being processed correctly. We are still monitoring the service.
This incident has been resolved.
We are facing issues with one of our providers and we see a slight decrease in clear rate for Identity Reports in UK jurisdiction
A fix has been implemented and we are monitoring the results. All clear rates should be back to normal
All reports are back to normal.
We cannot complete QES tasks because our electronic signature provider is encountering issues.
The provider is working on a fix.
Our provider fixed the issue. QES tasks are completing now. Tasks started during the incident were resumed.
The service is operational, no error where detected after the fix.
We noticed an issue with our QES tasks, we're investigating.
Our provider is experiencing issues. All QES tasks cannot complete for now.
Our provider is fixing the issue. QES tasks still cannot complete.
The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.
QES is operational again.
We identified an issue with one of our provider and some QES tasks may encounter some problems.
Our provider is still experiencing issues. All QES tasks cannot complete for now.
Our provider continues experiencing issues and is working on a fix.
Our provider is slowly recovering, we expect some QES tasks to complete.
QES is operational again.
