61 Onfido incidents · Mae 2025 — official updates, affected components, duration and resolution details.
Não podemos atualmente completar relatórios e tarefas do eVisa do Reino Unido por causa de uma falha do nosso provedor.
Os serviços do provedor foram restaurados, nossas tarefas no Reino Unido eVisas estão completando novamente.
Os nossos serviços estão operacionais novamente.
Traduzido automaticamente da atualização oficial do incidente.
Um de nossos provedores está tendo problemas, o que causará atrasos em alguns relatórios. Estamos a investigar a questão.
Nosso provedor ainda está tendo problemas. Estamos a acompanhar de perto a situação. O ID-UK é o nosso serviço mais impactado.
O provedor está ciente da questão. Ainda estamos prontos para retomar os nossos serviços assim que o problema estiver resolvido.
Nosso provedor é afetado por um grande incidente global em um de seus fornecedores, que está sendo trabalhado ativamente.
Os erros pararam. Estamos a monitorizar os nossos serviços para ter a certeza que tudo está de volta ao normal.
Os nossos serviços estão operacionais novamente.
Traduzido automaticamente da atualização oficial do incidente.
Estamos enfrentando problemas com nossos provedores e vemos Relatórios de Identidade não sendo processados na jurisdição do Reino Unido
A questão foi identificada e aplicou-se uma solução alternativa
Foi implementada uma correção e estamos monitorando os resultados.
Continuamos monitorando quaisquer outros problemas.
Este incidente foi resolvido
Traduzido automaticamente da atualização oficial do incidente.
Este serviço do Governo do Reino Unido está actualmente em baixo e não está disponível. Estamos monitorando a situação até que o serviço volte online.
Continuamos trabalhando em uma solução para esse problema.
O provedor de terceiros parece estar de volta online agora. Os controlos estão a ser processados. Continuando a acompanhar a situação.
O provedor de terceiros está de volta online. As verificações anteriores já foram processadas.
Traduzido automaticamente da atualização oficial do incidente.
Entre 14:30 e 15:30 UTC, os clientes da região da CA experimentaram acesso degradado à API pública. Uma implantação incorreta na camada de autenticação fez com que tokens válidos fossem incorretamente rejeitados, resultando em solicitações de API falhadas. A questão foi totalmente resolvida. Nenhuma ação é necessária no seu fim. Pedimos desculpa pela interrupção.
Traduzido automaticamente da atualização oficial do incidente.
De aproximadamente 1:21 PM UTC a 1:46 PM UTC, houve uma interrupção para aceitar solicitações de documentos do Web SDK, bem como Confiar IDV SDKs para fluxos contendo módulos web. Onfido Android & iOS SDKs não foram impactados. Pedimos desculpa por esta interrupção. Uma autópsia detalhada seguir-se-á assim que concluirmos a investigação.
Resumo Em 1 de setembro de 2026, das 13:21 UTC às 13:45 UTC, os usuários que tentavam capturar documentos na Web SDK não conseguiram terminar sua sessão. Isto também se estendeu para Native Entrust IDV SDK para configurações que contêm módulos web. Os SDKs nativos do Onfido Android e iOS não foram afetados. Causas Raízes Uma atualização de rotina para uma imagem de contêiner para o nosso serviço de configuração de documentos introduziu uma regressão para o trabalho de sincronização que atualiza a lista de documentos. Isso resultou no endpoint que nossos SDKs usam para buscar documentos retornando `500' erros. Isto impediu que os fluxos de SDK da Web continuassem. Nossos SDKs nativos usam uma lista de documentos de backup que lhes permitiu continuar como normal. Nossos progressivos lançamentos são projetados para pegar falhas de serviço antes que eles se tornem significativos. No entanto, a falha no trabalho de sincronização não marcou a sonda de prontidão como não saudável, de modo que o lançamento continuou. Linha do Tempo 13:10 UTC: Iniciamos uma progressiva implantação da mudança. 13:21 UTC : O serviço foi totalmente executado levando a erros na funcionalidade SDK impactada. 13:26 UTC: A monitorização alertou a equipa. 13:44 UTC: Causa identificada e mudança regredida. 13:45 UTC: Serviço restaurado. Remédios * Vamos adicionar cobertura de testes automatizados ausentes para garantir que nós pegar esses casos no futuro. * Vamos adicionar uma lista de documentos de retorno ao Web SDK, semelhante ao mecanismo presente nos SDKs nativos, para garantir que ele ainda pode funcionar no caso de quaisquer falhas futuras semelhantes. * Vamos corrigir a implantação progressiva para garantir que o lançamento não vai continuar no caso de que algo deu errado com a sincronização de documentos.
Traduzido automaticamente da atualização oficial do incidente.
Faces conhecidas experimentando taxas de consideração mais elevadas em todas as regiões.
# # Resumo Em 26 de agosto de 2026, observou-se aumento da taxa de consideração de Faces Conhecidas no período entre 15:00 e 18:00 UTC. A taxa de consideração global observada de Faces Conhecidas aumentou de ~6% para ~23% em todas as regiões. O aumento percebido pode ter sido maior ou menor, dependendo da geografia específica do cliente ou vertical. O foi impulsionado por uma mudança na forma como as pontuações correspondentes são calculadas para as partidas do Known Faces, que inflaram as pontuações para as faces não combinadoras e, assim, fazendo com que muitos relatórios retornassem falsas partidas e um resultado **consider**. # # Causas Raízes A mudança introduziu um novo algoritmo para marcar faces correspondentes, que se destina a melhorar o desempenho de recordação de faces conhecidas. Isto foi amplamente avaliado e validado por benchmarks internos antes de ser lançado. Inadvertidamente, a transição dos parâmetros de referência para a produção não teve parcialmente em conta características específicas do ambiente de produção. Na raiz, uma única constante não foi devidamente convertida na transição, resultando em comportamento errado do novo algoritmo de pontuação. # # Timeline 15:20 UTC: Mudança para Faces Conhecidas é lançada 17:35 UTC: Nota-se aumento da taxa de consideração em Faces Conhecidas. 17:50 UTC: Mudança é removida. Considere a taxa de quedas logo depois. # # Remédios Estamos a rever benchmarks internos e procedimentos de ensaio que podem aumentar a segurança deste tipo de mudança. Especificamente, garantir testes internos reflete o cenário real de produção quando se trata de conjuntos de dados e que as transições de benchmarks internos e experiências para a produção são completamente testadas. Além disso, os procedimentos de alteração serão realizados com um controlo mais rigoroso, permitindo-nos observar e agir mais rapidamente.
Traduzido automaticamente da atualização oficial do incidente.
Semelhança facial Os controlos das propostas utilizando desafios de aleatoriedade estão a falhar a uma taxa muito mais elevada do que o normal na região da UE.
# # Resumo Em 24 de Agosto de 2026, entre as 15:00 UTC e as 06:53 UTC, na manhã seguinte, as verificações da semelhança facial através de desafios de aleatoriedade falharam a uma taxa muito mais elevada do que o normal na região da UE. Foi aplicada uma validação mais rigorosa a todos os clientes da região, quando deveria ter sido limitada a um único cliente, causando verificações que de outra forma teriam sido rejeitadas. Relatos afetados foram retornados com uma falha de "Autenticidade Visual". Como as verificações de movimento são totalmente automatizadas, os usuários finais por trás desses relatórios foram rejeitados sem revisão manual, e alguns tentaram novamente a verificação e foram rejeitados uma segunda vez. A taxa clara para esses controles caiu de cerca de 97% para cerca de 54% para aproximadamente 1,67% dos relatórios de Similaridade Facial Motion foram afetados. A desactivação da alteração restaurou imediatamente as taxas normais de limpeza. Outros controlos da moção e outras regiões não foram afectados. # # Causas Raízes Uma validação mais rigorosa do desafio de aleatoriedade de movimento estava sendo testada com um único cliente, controlado por uma configuração por cliente. Um bug no nosso código significava que a configuração foi avaliada sem o identificador do cliente, de modo que a validação mais rigorosa foi aplicada a todos os clientes da região da UE executando Motion com verificações de aleatoriedade em vez do pretendido. As verificações que passariam sob a validação padrão foram rejeitadas e relatadas sob a "Autenticidade Visual". Nenhuma configuração do cliente ou dados enviados foi falha. # # Timeline Todas as vezes UTC. * 24 de Agosto de 15:00: permitiu uma validação mais rigorosa dos desafios da aleatoriedade dos movimentos na região da UE. Verificações de movimento usando aleatoriedade começaram a falhar a uma taxa muito maior. * 24 de agosto de 16:36: um cliente relatou uma queda nas taxas de sucesso do fluxo de trabalho e começamos a investigar. * 25 de agosto de 04:18: confirmamos a taxa de falha elevada e a escalamos. * 25 de agosto de 06:53: revertemos a mudança e as taxas claras voltaram ao normal em minutos. * 26 de agosto: lançamos uma correção permanente. # # Remédios * Fortalecer os controles em torno de mudanças de configuração específicas do cliente para garantir que eles não podem ser aplicados mais amplamente do que o pretendido. * Melhore o monitoramento e o alerta para a aleatoriedade do movimento, de modo que mudanças inesperadas nas taxas de rejeição sejam detectadas automaticamente e intensificadas mais rapidamente.
Traduzido automaticamente da atualização oficial do incidente.
Estamos atualmente investigando atrasos em nosso cluster dos EUA para o processamento de relatórios de Semelhança Facial, Document e Faces Conhecidas.
Estamos vendo desempenho degradado de alguns nós em nosso cluster de busca de faces indexadas. Continuamos a investigar a causa da raiz e possíveis remediações.
Identificamos a causa raiz do desempenho degradado em nosso cluster de busca dos EUA e estamos trabalhando ativamente para resolvê-lo. Seguiremos uma vez totalmente restaurados.
Implementamos uma correção e continuamos a monitorar a qualidade do tempo de processamento, que agora é melhorado.
O tempo de processamento continua a melhorar, todos os sistemas estão operacionais.
Os tempos de processamento voltaram ao normal. Esta questão está agora resolvida. - Depois da morte.
Traduzido automaticamente da atualização oficial do incidente.
Identity Enhanced está experimentando uma redução importante nas taxas claras para os candidatos todos os outros países, exceto o Reino Unido
Estamos trabalhando com nosso provedor de terceiros para resolver o problema e compartilharemos atualizações à medida que estiverem disponíveis.
Continuamos trabalhando em uma solução para esse problema.
Estamos vendo a recuperação de serviço do nosso provedor e solicitar taxas de sucesso melhorando. Continuamos a acompanhar de perto a situação.
O provedor resolveu o problema, e o serviço está agora operando normalmente
Traduzido automaticamente da atualização oficial do 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.
