61 incidente Onfido înregistrate începând din mai 2025, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
În prezent nu putem completa rapoartele și sarcinile eVisa din Marea Britanie din cauza unei întreruperi a furnizorului nostru.
Serviciile furnizorului au fost restaurate, sarcinile noastre eVisas din Marea Britanie sunt finalizate din nou.
Serviciile noastre sunt operaţionale din nou.
Traducere automată din actualizarea oficială a incidentului.
Unul dintre furnizorii noştri are probleme, ceea ce va cauza întârzieri în unele rapoarte. Investigăm problema.
Furnizorul nostru încă se confruntă cu probleme. Monitorizăm îndeaproape situaţia. ID-UK este serviciul nostru cel mai afectat.
Furnizorul este conștient de această problemă. Suntem încă gata să ne reluăm serviciile imediat ce rezolvăm problema.
Furnizorul nostru este afectat de un incident global major la unul dintre furnizorii săi, care este activ în curs de lucru.
Erori oprite. Ne monitorizăm serviciile pentru a ne asigura că totul revine la normal.
Serviciile noastre sunt operaţionale din nou.
Traducere automată din actualizarea oficială a incidentului.
Ne confruntăm cu probleme cu furnizorii noștri și vedem că rapoartele de identitate nu sunt prelucrate în jurisdicția Regatului Unit
Problema a fost identificată și am aplicat o abordare
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat
Traducere automată din actualizarea oficială a incidentului.
Acest serviciu al guvernului britanic este în prezent în scădere și nu este disponibil. Monitorizăm situaţia până când serviciul revine online.
Continuăm să lucrăm la o soluție pentru această problemă.
Cel de-al treilea furnizor de partid pare să fie din nou online acum. Controalele sunt procesate. Continuă să monitorizeze situaţia.
Cel de-al treilea furnizor de partid este din nou online. Controalele anterioare blocate au fost procesate acum.
Traducere automată din actualizarea oficială a incidentului.
Între 14:30 și 15:30 UTC, clienții din regiunea CA au avut acces degradat la API-ul public. O implementare defectuoasă în stratul de autentificare a determinat respingerea incorectă a jetoanelor valabile, ceea ce a dus la cereri API eșuate. Problema a fost rezolvată pe deplin. Nu este necesară nicio acţiune din partea ta. Ne cerem scuze pentru întrerupere.
Traducere automată din actualizarea oficială a incidentului.
De la aproximativ 1:21 PM UTC la 1:46 PM UTC, a existat o perturbare a acceptării cererilor de documente de la Web SDK, precum și Entrust IDV SDKs pentru fluxurile care conțin module web. Onfido Android & iOS SDKs nu au fost afectate. Ne cerem scuze pentru această întrerupere. O autopsie detaliată va urma după ce terminăm investigaţia.
### Rezumat La 1 septembrie 2026, de la 13:21 UTC la 13:45 UTC, utilizatorii care încercau să captureze documente în Web SDK nu au putut să-și termine sesiunea. Acest lucru a extins, de asemenea, la nativ Entrust IDV SDK Native Onfido Android și iOS SDKs au fost neafectate. ### Root Causes O actualizare de rutină la o imagine container pentru serviciul nostru de configurare document a introdus o regresie la locul de muncă de sincronizare care actualizează lista documentelor. Acest lucru a dus la obiectivul pe care SDK-urile noastre îl folosesc pentru a aduce documente care returnează Acest lucru a împiedicat fluxurile web SDK să continue. Nativii noştri SDK folosesc o listă de documente de rezervă care le-a permis să continue ca de obicei. Lansările noastre progresive sunt concepute pentru a prinde defecte de serviciu înainte de a deveni semnificative. Cu toate acestea, eșecul de locuri de muncă de sincronizare nu a marcat sonda de pregătire ca nesănătos, astfel încât lansarea a continuat. ### Timeline 13:10 UTC: Am început o lansare progresivă a schimbării. 13:21 UTC : Serviciul a fost complet rulat conducând la erori privind funcționalitatea SDK afectată. 13:26 UTC: Monitorizarea a alertat echipa. 13:44 UTC: Cauza identificat și schimbare laminate înapoi. 13:45 UTC: Serviciu restaurat. ### Remedii * Vom adăuga o acoperire de testare automată lipsă pentru a ne asigura că vom prinde aceste cazuri în viitor. * Vom adăuga o listă de documente de rezervă la Web SDK, similar cu mecanismul prezent în SDKs native, pentru a se asigura că poate funcționa în continuare în cazul oricăror eșecuri viitoare similare. * Vom repara rollout progresiv pentru a se asigura că rollout nu va continua în cazul în care ceva a mers prost cu sincronizarea documentelor.
Traducere automată din actualizarea oficială a incidentului.
Chipurile cunoscute care se confruntă cu rate mai ridicate iau în considerare toate regiunile.
## Rezumat La 26 august 2026 a fost observată o creștere a ratei de examinare a fețelor cunoscute în perioada cuprinsă între orele 15:00 și 18:00 UTC. În ansamblu, rata de evaluare a fețelor cunoscute a crescut de la ~6% la ~23% în toate regiunile. Creșterea percepută poate fi mai mare sau mai mică, în funcție de geografia specifică a clientului sau verticală. A fost condus de o schimbare a modului în care scorurile de potrivire sunt calculate pentru meciurile cu Fațe cunoscute, care a umflat scorurile pentru fețele care nu se potrivesc și, astfel, cauzând multe rapoarte pentru a returna meciuri false și un rezultat **considere**. ## Root Causes Modificarea a introdus un nou algoritm de notare a fețelor de potrivire, care este destinat să îmbunătățească performanța de rechemare a fețelor cunoscute. Aceasta a fost evaluată și validată pe scară largă de criteriile de referință interne înainte de a fi eliberată. În mod nejustificat, tranziția de la indicii de referință la producție nu a ținut seama parțial de caracteristicile specifice ale mediului de producție. La rădăcină, o singură constantă nu a fost convertit în mod corespunzător în tranziție, rezultând în comportament greșit al noului algoritm de notare. ## Timeline 15:20 UTC: Schimbarea la fețe cunoscute este eliberat 17:35 UTC: Creșterea ratei de luat în considerare pe fețe cunoscute este observat. 17:50 UTC: Schimbarea este rulat înapoi. Consideră că rata scade curând după aceea. ## Remedii Examinăm criteriile de referință interne și procedurile de testare care pot spori siguranța acestui tip de schimbare. În special, asigurarea testării interne reflectă peisajul real al producției atunci când vine vorba de seturi de date și că tranzițiile de la indici interni de referință și experimente la producție sunt testate în detaliu. În plus, procedurile de schimbare vor fi efectuate cu o monitorizare mai strictă, astfel încât ne permite să observăm și să acționăm mai rapid.
Traducere automată din actualizarea oficială a incidentului.
Controale ale mișcării de similitudine facială prin utilizarea unor provocări aleatorii sunt într-un ritm mult mai ridicat decât cel normal în regiunea UE.
## Rezumat La 24 august 2026, între orele 15:00 UTC și 06:53 UTC în dimineața următoare, verificări ale mișcării de apropiere facială, utilizând provocări aleatorii, au eșuat într-un ritm mult mai ridicat decât normal în regiunea UE. S-a aplicat o validare mai strictă tuturor clienților din regiune atunci când ar fi trebuit să se limiteze la un singur client, ceea ce a determinat respingerea verificărilor care altfel ar fi trecut. Rapoartele afectate au fost returnate cu un eșec "Autenticitatea vizuală." Deoarece controalele de mișcare sunt complet automatizate, utilizatorii finali din spatele acestor rapoarte au fost respinși fără o revizuire manuală, iar unii au încercat din nou verificarea și au fost respinși pentru a doua oară. Rata clară a acestor controale a scăzut de la aproximativ 97% la aproximativ 54% pentru aproximativ 1,67% din rapoartele privind mișcarea facială de apropiere. Dezactivarea schimbare restaurat rate normale clare imediat. Alte controale ale mișcării și alte regiuni nu au fost afectate. ## Root Causes O validare mai strictă a provocării mișcării aleatorii a fost testată cu un singur client, controlat de un set de configurare per client. Un bug din codul nostru a însemnat că setarea a fost evaluată fără identificatorul clientului, astfel încât validarea mai strictă a fost aplicată tuturor clienților din regiunea UE care rulează Moțiunea cu controale aleatorii, mai degrabă decât cu cele prevăzute. În schimb, au fost respinse verificările care ar fi trecut în conformitate cu validarea standard și raportate în cadrul defalcarei "Autenticității vizuale." Nicio configurație a clientului sau date transmise nu au fost de vină. ## Timeline Tot timpul UTC. * 24 august, 15:00: am permis o validare mai strictă a provocărilor legate de caracterul aleatoriu al mișcării în regiunea UE. Controalele de mișcare folosind aleatorii a început să scadă la o rată mult mai mare. * 24 august, 16:36: un client a raportat o scădere a ratei de succes a fluxului de lucru şi am început să investigăm. * 25 August, 04:18: am confirmat rata ridicată de eșec și am escaladat-o. * 25 August, 06:53: am revenit la normal în câteva minute. * 26 august: am implementat un fix permanent. ## Remedii * Consolidarea controalelor în jurul schimbărilor de configurare specifice clientului pentru a se asigura că acestea nu pot fi aplicate mai larg decât se intenționează. * Îmbunătățește monitorizarea și alertarea pentru Motion aleatorie controale clare rata, astfel încât modificările neașteptate ale ratelor de respingere sunt detectate automat și au crescut mai repede.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm întârzieri în grupul nostru american pentru procesarea rapoartelor privind similaritatea facială, documentele și fețele cunoscute.
Vedem performanţe degradate ale unor noduri din grupul nostru de căutare pentru feţe indexate. Continuăm să investigăm cauza principală şi posibilele reparaţii.
Am identificat cauza principală a performanţei degradate în grupul nostru de căutare din SUA şi lucrăm activ pentru a o rezolva. Vom urmări o dată restaurat complet.
Am implementat un fix și continuăm să monitorizăm calitatea timpului de procesare, care este acum îmbunătățit.
Timpul de procesare continuă să se îmbunătățească, toate sistemele sunt acum operaționale.
Timpul de procesare a revenit la normal. Această problemă este acum rezolvată. Post-mortem va urma în curând.
Traducere automată din actualizarea oficială a incidentului.
Identitatea îmbunătățită se confruntă cu o scădere majoră a ratelor clare pentru solicitanții din întreaga lume, cu excepția Regatului Unit
Lucrăm cu furnizorul nostru terţ pentru a rezolva problema şi vom face schimb de actualizări pe măsură ce acestea devin disponibile.
Continuăm să lucrăm la o soluție pentru această problemă.
Vedem recuperarea serviciilor furnizorului nostru și solicităm îmbunătățirea ratelor de succes. Continuăm să monitorizăm îndeaproape situaţia.
Furnizorul a rezolvat problema, iar serviciul funcționează în mod normal
Traducere automată din actualizarea oficială a incidentului.
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.
