61 Onfido incidents · mai 2025 — official updates, affected components, duration and resolution details.
Nous ne pouvons actuellement pas compléter les rapports et les tâches UK eVisa en raison d'une panne de notre fournisseur.
Les services du fournisseur ont été restaurés, nos tâches eVisas UK sont à nouveau terminées.
Nos services sont de nouveau opérationnels.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
L'un de nos fournisseurs a des problèmes, ce qui causera des retards dans certains rapports. Nous enquêtons sur le problème.
Notre fournisseur connaît toujours des problèmes. Nous suivons de près la situation. ID-UK est notre service le plus touché.
Le fournisseur est au courant du problème. Nous sommes toujours prêts à reprendre nos services dès que le problème sera résolu.
Notre fournisseur est touché par un incident mondial majeur chez l'un de ses fournisseurs, qui est activement travaillé sur.
Les erreurs se sont arrêtées. Nous surveillons nos services pour nous assurer que tout est de retour à la normale.
Nos services sont de nouveau opérationnels.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous sommes confrontés à des problèmes avec nos fournisseurs et nous voyons que les rapports d'identité ne sont pas traités dans la juridiction britannique
Le problème a été identifié et nous avons appliqué une solution de rechange
Un correctif a été mis en place et nous suivons les résultats.
Nous restons à l'affût de tout autre problème.
Cet incident a été résolu
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Ce service du gouvernement britannique est actuellement en baisse et n'est pas disponible. Nous surveillons la situation jusqu'à ce que le service revienne en ligne.
Nous continuons de travailler sur une solution à ce problème.
3e fournisseur de partie semble être de retour en ligne maintenant. Des vérifications sont en cours. Continuer à surveiller la situation.
3ème fournisseur de parties est de retour en ligne. Les vérifications précédemment bloquées ont été traitées maintenant.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Entre 14h30 et 15h30 UTC, les clients de la région CA ont connu un accès dégradé à l'API publique. Un déploiement défectueux dans la couche d'authentification a causé le rejet incorrect des jetons valides, ce qui a entraîné une erreur dans les requêtes d'API. La question a été entièrement réglée. Aucune action n'est nécessaire à votre fin. Nous nous excusons pour la perturbation.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
De 13h21 à 13h46 UTC, il y a eu une perturbation à accepter les demandes de documents du SDK Web ainsi que les SDK IDV Entrust pour les flux contenant des modules Web. Onfido Android et iOS SDKs n'ont pas été touchés. Nous nous excusons pour cette perturbation. Un post mortem détaillé suivra une fois notre enquête terminée.
Résumé Le 1er septembre 2026, de 13h21 UTC à 13h45 UTC, les utilisateurs qui tentaient de capturer des documents dans le SDK Web n'ont pas pu terminer leur session. Cela s'est également étendu aux SDK idnative Entrust pour les configurations contenant des modules web. Native Onfido Android et iOS SDKs n'ont pas été touchés. Causes profondes Une mise à jour de routine d'une image de conteneur pour notre service de configuration de document a introduit une régression à la tâche de synchronisation qui met à jour la liste de documents. Cela a donné lieu au paramètre que nos SDK utilisent pour récupérer des documents renvoyant des erreurs `500`. Cela a empêché les flux de SDK web de continuer. Nos SDK natifs utilisent une liste de documents de sauvegarde qui leur a permis de continuer normalement. Nos déploiements progressifs sont conçus pour attraper les défauts de service avant qu'ils ne deviennent significatifs. Cependant, l'échec du travail de synchronisation n'a pas marqué la sonde de préparation comme malsaine, de sorte que le déploiement a continué. Calendrier 13:10 UTC: Nous avons commencé un déploiement progressif du changement. 13:21 UTC : Le service a été entièrement déployé, ce qui a entraîné des erreurs dans la fonctionnalité SDK. 13:26 UTC: La surveillance a alerté l'équipe. 13:44 UTC: Cause identifiée et changement retourné. 13:45 UTC: Service restauré. Recours * Nous ajouterons la couverture des tests automatisés manquants pour nous assurer que nous captons ces cas à l'avenir. * Nous ajouterons une liste de documents de retour au SDK Web, semblable au mécanisme présent dans les SDK natifs, pour nous assurer qu'il peut encore fonctionner en cas d'échecs similaires futurs. * Nous allons fixer le déploiement progressif pour s'assurer que le déploiement ne se poursuivra pas dans le cas où quelque chose a mal tourné avec la synchronisation des documents.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Les visages connus qui connaissent des taux de prise en compte plus élevés dans toutes les régions.
Résumé Le 26 août 2026, une augmentation du taux de prise en compte des visages connus a été observée entre 15 h et 18 h UTC. Le taux global de prise en compte des visages connus est passé d'environ 6 % à environ 23 % dans toutes les régions. L'augmentation perçue peut avoir été plus ou moins élevée, selon la géographie spécifique ou verticale du client. Le changement a été provoqué par un changement à la façon dont les scores de correspondance sont calculés pour les matchs de visages connus, qui a gonflé les scores pour les visages non appariés et a donc causé de nombreux rapports de retourner de faux matchs et un résultat **considér**. Causes profondes Le changement a introduit un nouvel algorithme pour la notation des visages correspondants, qui vise à améliorer la performance de rappel des visages connus. Cette méthode a été largement évaluée et validée par des repères internes avant d'être publiée. Inopportunement, le passage des critères de référence à la production n'a pas tenu compte en partie des caractéristiques particulières de l'environnement de production. À la racine, une seule constante n'a pas été correctement convertie dans la transition, entraînant un mauvais comportement du nouvel algorithme de notation. Calendrier 15:20 UTC: Changer vers les visages connus est publié 17:35 UTC: Augmentation du taux de considération sur les visages connus est remarqué. 17:50 UTC: Le changement est retourné. Considérez les baisses de taux peu après. Recours Nous étudions les critères internes et les procédures d'essai qui peuvent accroître la sécurité de ce type de changement. Plus précisément, veiller à ce que les tests internes reflètent le paysage réel de la production en ce qui concerne les ensembles de données et à ce que les transitions entre les repères et les expériences internes à la production soient soigneusement testées. En outre, les procédures de changement seront effectuées avec une surveillance plus étroite afin de nous permettre de remarquer et d'agir plus rapidement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Similarité faciale Les contrôles de mouvements effectués à l'aide de défis aléatoires échouent à un rythme beaucoup plus élevé que la normale dans la région de l'UE.
Résumé Le 24 août 2026, entre 15h00 UTC et 06h53 UTC le matin suivant, Facial Simility Motion checks utilisant des défis aléatoires a échoué à un taux beaucoup plus élevé que la normale dans la région de l'UE. Une validation plus stricte a été appliquée à tous les clients de la région lorsqu'elle aurait dû être limitée à un seul client, ce qui aurait entraîné le rejet de vérifications qui auraient autrement été passées. Les rapports touchés ont été retournés avec un échec "authenticité visuelle". Comme les vérifications des mouvements sont entièrement automatisées, les utilisateurs finals derrière ces rapports ont été rejetés sans examen manuel, et certains ont tenté de nouveau la vérification et ont été rejetés une deuxième fois. Le taux clair de ces vérifications est passé d'environ 97 % à environ 54 % pour environ 1,67 % des rapports de mouvement de similitude faciale. La désactivation du changement a rétabli immédiatement les taux normaux. D'autres vérifications des mouvements et d'autres régions n'ont pas été effectuées. Causes profondes Une validation plus stricte du défi de l'aléatoire de mouvement a été testée avec un seul client, contrôlé par un réglage de configuration par client. Un bug dans notre code signifiait que le réglage a été évalué sans l'identificateur du client, de sorte que la validation plus stricte a été appliquée à tous les clients de la région de l'UE exécutant Motion avec des contrôles aléatoires plutôt que celui prévu. Les vérifications qui auraient été effectuées dans le cadre de la validation standard ont plutôt été rejetées et déclarées dans la ventilation « Authenticité visuelle ». Aucune configuration client ou données soumises n'était en cause. Calendrier Toutes les fois UTC. * 24 août, 15:00: nous avons permis une validation plus stricte des défis du hasard de mouvement dans la région de l'UE. Les contrôles de mouvements effectués au hasard ont commencé à échouer à un rythme beaucoup plus élevé. * 24 août, 16h36 : un client a signalé une baisse des taux de réussite du workflow et nous avons commencé à enquêter. * 25 août, 04:18: nous avons confirmé le taux élevé d'échec et l'avons augmenté. * 25 août, 06:53 : nous avons repris le changement et les taux clairs sont revenus à la normale en quelques minutes. * 26 août : nous avons déployé une solution permanente. Recours * Renforcer les contrôles autour des changements de configuration spécifiques au client pour s'assurer qu'ils ne peuvent pas être appliqués plus largement que prévu. * Améliorer la surveillance et l'alerte pour les mouvements aléatoires des contrôles de taux clairs afin que les changements inattendus dans les taux de rejet soient détectés automatiquement et augmentés plus rapidement.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur les retards dans notre grappe américaine pour le traitement des rapports de similitude faciale, de documents et de visages connus.
Nous voyons des performances dégradées de certains nœuds dans notre grappe de recherche de visages indexés. Nous continuons d'étudier la cause fondamentale et les mesures correctives possibles.
Nous avons identifié la cause profonde de la dégradation des performances dans notre grappe de recherche américaine et nous travaillons activement à la résoudre. Nous ferons le suivi une fois entièrement restauré.
Nous avons mis en place un correctif et continuons de surveiller la qualité du temps de traitement, qui est maintenant amélioré.
Le temps de traitement continue à s'améliorer, tous les systèmes sont maintenant opérationnels.
Les temps de traitement sont de retour à la normale. Cette question est maintenant résolue. Après mortem à suivre bientôt.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Identity Enhanced connaît une baisse importante des taux nets pour les candidats dans le monde entier, sauf au Royaume-Uni
Nous travaillons avec notre fournisseur tiers pour résoudre le problème et partagerons les mises à jour dès qu'elles seront disponibles.
Nous continuons de travailler sur une solution à ce problème.
Nous constatons une amélioration du taux de récupération du service de notre fournisseur et des taux de réussite des demandes. Nous continuons de suivre de près la situation.
Le fournisseur a résolu le problème et le service fonctionne maintenant normalement
Traduit automatiquement depuis la mise à jour officielle de l'incident.
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.
