61 Onfido incidents · maggio 2025 — official updates, affected components, duration and resolution details.
Attualmente non possiamo completare i rapporti e le attività UK eVisa a causa di un outage del nostro fornitore.
I servizi del fornitore sono stati ripristinati, i nostri compiti UK eVisas stanno completando di nuovo.
I nostri servizi sono di nuovo operativi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Uno dei nostri fornitori sta avendo problemi, che causerà ritardi su alcuni rapporti. Stiamo indagando sul problema.
Il nostro fornitore sta ancora vivendo problemi. Stiamo monitorando attentamente la situazione. ID-UK è il nostro servizio più impatto.
Il fornitore è a conoscenza del problema. Siamo ancora pronti a riprendere i nostri servizi non appena il problema è risolto.
Il nostro fornitore è interessato da un importante incidente globale a uno dei suoi fornitori, che sta attivamente lavorando.
Gli errori si sono fermati. Stiamo monitorando i nostri servizi per assicurarci che tutto torni alla normalità.
I nostri servizi sono di nuovo operativi.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Siamo di fronte a problemi con i nostri fornitori e vediamo Identity Reports non essere trattati nella giurisdizione del Regno Unito
Il problema è stato identificato e abbiamo applicato una soluzione
Una soluzione è stata implementata e stiamo monitorando i risultati.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Questo incidente è stato risolto
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Questo servizio del governo del Regno Unito è attualmente in diminuzione e non disponibile. Stiamo monitorando la situazione finché il servizio non torna online.
Stiamo continuando a lavorare per risolvere questo problema.
Il terzo fornitore di partito sembra essere tornato online ora. I controlli sono in fase di elaborazione. Proseguendo per monitorare la situazione.
Il terzo fornitore di partito è tornato online. I controlli precedentemente bloccati sono stati elaborati ora.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Tra le 14:30 e le 15:30 UTC, i clienti nella regione CA hanno sperimentato l'accesso degradato alle API pubbliche. Una distribuzione difettosa nello strato di autenticazione ha causato token validi per essere respinti in modo errato, con conseguente richieste API fallite. Il problema è stato completamente risolto. Non è richiesta alcuna azione alla fine. Ci scusiamo per l'interruzione.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Da circa 1:21 PM UTC a 1:46 PM UTC, c'è stata una rottura per accettare le richieste di documenti dal Web SDK e Entrust IDV SDKs per flussi contenenti moduli web. Onfido Android & iOS SDKs non sono stati influenzati. Ci scusiamo per questa rottura. Un postmortem dettagliato seguirà una volta conclusa la nostra indagine.
## Il 1 settembre 2026, dalle 13:21 UTC alle 13:45 UTC, gli utenti che tentano di catturare documenti nel Web SDK non sono stati in grado di finire la loro sessione. Questo anche esteso al nativo Entrust IDV SDK per configurazioni che contengono moduli web. I nativi Onfido Android e iOS SDK non sono stati colpiti. ## Cause della radice Un aggiornamento di routine a un'immagine del contenitore per il nostro servizio di configurazione del documento ha introdotto una regressione al lavoro di sincronizzazione che aggiorna l'elenco dei documenti. Ciò ha portato al punto finale che i nostri SDK utilizzano per recuperare i documenti di ritorno `500` errori. Questo ha impedito i flussi di SDK web da procedere. I nostri SDKs nativi utilizzano un elenco di documenti di backup che ha permesso loro di continuare come normale. I nostri roll-out progressivi sono progettati per catturare guasti di servizio prima che diventino significativi. Tuttavia, il fallimento del lavoro di sincronizzazione non ha segnato la sonda di prontezza come malsano, così il rollout ha continuato. ## Timeline 13:10 UTC: Abbiamo iniziato un progressivo rollout del cambiamento. 13:21 UTC : Il servizio è stato completamente implementato portando a errori sulla funzionalità SDK. 13:26 UTC: Il monitoraggio ha avvisato la squadra. 13:44 UTC: Causa identificata e cambiamento rotolato indietro. 13:45 UTC: Servizio restaurato. ### Remedies * Aggiungiamo la copertura di test automatizzata mancante per garantire che prendiamo questi casi in futuro. * Aggiungiamo un elenco di documenti fallback al SDK Web, simile al meccanismo presente negli SDK nativi, per garantire che possa ancora funzionare nel caso di eventuali guasti futuri simili. * Correggeremo il rollout progressivo per garantire che il rollout non continuerà nel caso in cui qualcosa è andato storto con documenti sincronizzanti.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
I volti noti che sperimentano tassi più alti considerano in tutte le regioni.
# Il 26 agosto 2026, è stato osservato un aumento del tasso di considerazione dei volti noti durante il periodo tra le 15:00 e le 18:00 UTC. Il tasso di riferimento complessivo osservato è aumentato dal ~6% al ~23% in tutte le regioni. L'aumento percepito può essere stato maggiore o inferiore, a seconda della geografia specifica del cliente o verticale. Il risultato è stato guidato da un cambiamento nel modo in cui i punteggi corrispondenti sono calcolati per le partite di Known Faces, che gonfiano i punteggi per le facce non-matching e quindi causando molti rapporti per restituire le partite false e un risultato **consider**. # Cause della radice Il cambiamento ha introdotto un nuovo algoritmo per segnare i volti corrispondenti, che è destinato a migliorare le prestazioni di richiamo Known Faces. Questo è stato ampiamente valutato e convalidato da benchmark interni prima di essere rilasciato. Inavvertitamente, il passaggio dai benchmark alla produzione in parte non ha tenuto conto di particolari caratteristiche ambientali di produzione. Alla radice, una singola costante non è stata correttamente convertita nella transizione, con conseguente comportamento sbagliato del nuovo algoritmo di punteggio. # Timeline 15:20 UTC: Change to Known Faces è rilasciato 17:35 UTC: aumento tasso di considerare su volti noti è notato. 17:50 UTC: Il cambiamento è rotolato indietro. Considerare le gocce di tasso subito dopo. # Stiamo esaminando i benchmark interni e le procedure di test che possono aumentare la sicurezza di questo tipo di cambiamento. In particolare, garantire la sperimentazione interna riflette il reale paesaggio di produzione quando si tratta di dataset e che le transizioni da benchmark interni e esperimenti alla produzione sono accuratamente testate. Inoltre, le procedure di cambiamento saranno effettuate con un monitoraggio più stretto in modo da permette di notare e agire più velocemente.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
I controlli di mozione di somiglianza facciale che utilizzano le sfide di casualità stanno fallendo ad un tasso molto più alto del normale nella regione dell'UE.
# Il 24 agosto 2026, tra le 15:00 UTC e le 06:53 UTC la mattina seguente, Facial Simility Motion controlli utilizzando le sfide di casualità fallito ad un tasso molto più alto del normale nella regione dell'UE. Una validazione più rigorosa è stata applicata a tutti i clienti della regione quando avrebbe dovuto essere limitata a un singolo cliente, causando verifiche che altrimenti sarebbero passate per essere rifiutate. I rapporti interessati sono stati restituiti con un fallimento "Autenticità Visuale". Poiché i controlli Motion sono completamente automatizzati, gli utenti finali dietro queste relazioni sono stati respinti senza alcuna revisione manuale, e alcuni hanno tentato di nuovo il controllo e sono stati respinti una seconda volta. Il tasso chiaro di questi controlli è sceso da circa il 97% a circa il 54% per circa il 1,67% dei rapporti di mozione di somiglianza facciale sono stati colpiti. Disattivare il cambiamento ripristinato normali tariffe chiare immediatamente. Altri controlli di movimento e altre regioni non sono stati colpiti. # Cause della radice Una più rigorosa convalida della sfida di casualità del movimento è stata sperimentata con un singolo cliente, controllato da un'impostazione di configurazione per cliente. Un bug nel nostro codice ha significato che l'impostazione è stata valutata senza l'identificatore del cliente, quindi la convalida più rigorosa è stata applicata a tutti i clienti nella regione dell'UE che eseguono Motion con controlli di casualità piuttosto che a quello previsto. Le verifiche che sarebbero passate sotto la validazione standard sono state respinte e riportate sotto la ripartizione "Autenticità Visuale". Nessuna configurazione del cliente o dati inviati è stata difettosa. # Timeline Sempre UTC. * 24 agosto, 15:00: abbiamo abilitato una più rigorosa validazione per le sfide di casualità del movimento nella regione dell'UE. I controlli di movimento che utilizzano la casualità hanno cominciato a fallire ad un tasso molto più alto. * 24 agosto, 16:36: un cliente ha riferito un calo dei tassi di successo del flusso di lavoro e abbiamo iniziato a indagare. * 25 agosto, 04:18: abbiamo confermato il tasso di guasto elevato e aumentato. * 25 agosto, 06:53: abbiamo annullato il cambiamento e le tariffe chiare tornate alla normalità in pochi minuti. * 26 agosto: abbiamo implementato una fissazione permanente. # * Rafforzare i controlli intorno alle modifiche di configurazione specifiche del cliente per garantire che non possano essere applicati in modo più ampio che previsto. * Migliorare il monitoraggio e l'avviso per i controlli a tasso chiaro di movimento in modo che i cambiamenti inaspettati nei tassi di rifiuto vengono rilevati automaticamente e intensificati più rapidamente.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando i ritardi nel nostro cluster degli Stati Uniti per il trattamento dei rapporti di somiglianza, documento e volti noti.
Stiamo vedendo le prestazioni degradate di alcuni nodi nel nostro cluster di ricerca per i volti indicizzati. Continuiamo a indagare la causa principale e le possibili correzioni.
Abbiamo identificato la causa principale delle prestazioni degradate nel nostro cluster di ricerca statunitense e stiamo lavorando attivamente per risolverlo. Seguiremo una volta completamente restaurato.
Abbiamo implementato una correzione e continuiamo a monitorare la qualità del tempo di elaborazione, che ora è migliorato.
Il tempo di lavorazione continua a migliorare, tutti i sistemi sono ora operativi.
I tempi di lavorazione sono tornati alla normalità. Questo problema è ora risolto. Post-mortem da seguire presto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Identity Enhanced sta vivendo una diminuzione importante delle tariffe chiare per i candidati di tutto il mondo tranne Regno Unito
Stiamo lavorando con il nostro fornitore di terze parti per risolvere il problema e condividere gli aggiornamenti come diventano disponibili.
Stiamo continuando a lavorare per risolvere questo problema.
Stiamo vedendo il recupero dei servizi del nostro fornitore e chiediamo il miglioramento dei tassi di successo. Continuiamo a monitorare attentamente la situazione.
Il fornitore ha risolto il problema e il servizio è ora operativo normalmente
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
