61 incidentes de Onfido registrados desde mayo de 2025, con actualizaciones oficiales, componentes afectados, duración y detalles de resolución.
Actualmente no podemos completar los informes y tareas de UK eVisa debido a un outage de nuestro proveedor.
Los servicios del proveedor han sido restaurados, nuestras tareas de eVisas del Reino Unido están terminando de nuevo.
Nuestros servicios están funcionando de nuevo.
Traducido automáticamente desde la actualización oficial del incidente.
Uno de nuestros proveedores está teniendo problemas, lo que causará retrasos en algunos informes. Estamos investigando el tema.
Nuestro proveedor sigue experimentando problemas. Estamos monitoreando la situación. ID-UK es nuestro servicio más impactado.
El proveedor es consciente del problema. Todavía estamos listos para reanudar nuestros servicios tan pronto como se resuelva el problema.
Nuestro proveedor se ve afectado por un importante incidente mundial en uno de sus proveedores, que se está trabajando activamente.
Los errores se detuvieron. Estamos monitoreando nuestros servicios para asegurarnos de que todo vuelva a la normalidad.
Nuestros servicios están funcionando de nuevo.
Traducido automáticamente desde la actualización oficial del incidente.
Nos enfrentamos a problemas con nuestros proveedores y vemos que los Informes de Identidad no se procesan en la jurisdicción del Reino Unido
La cuestión se ha identificado y hemos aplicado una solución de trabajo
Se ha aplicado una solución y estamos monitoreando los resultados.
Continuamos monitoreando cualquier otro problema.
Este incidente se ha resuelto
Traducido automáticamente desde la actualización oficial del incidente.
Este servicio del Gobierno del Reino Unido está actualmente bajo y no está disponible. Estamos monitoreando la situación hasta que el servicio vuelva en línea.
Seguimos trabajando en una solución para esta cuestión.
El proveedor de terceros parece estar de vuelta en línea ahora. Se están procesando los cheques. Seguir vigilando la situación.
El proveedor de terceros está de vuelta en línea. Los cheques previamente atascados han sido procesados ahora.
Traducido automáticamente desde la actualización oficial del incidente.
Entre 14:30 y 15:30 UTC, los clientes de la región de CA experimentaron un acceso degradado a la API pública. Un despliegue defectuoso en la capa de autenticación causó que se rechazaran las fichas válidas, lo que dio lugar a solicitudes de API fallidas. La cuestión se ha resuelto plenamente. No se requiere acción en su extremo. Nos disculpamos por la interrupción.
Traducido automáticamente desde la actualización oficial del incidente.
De aproximadamente 1:21 PM UTC a 1:46 PM UTC, hubo una interrupción para aceptar solicitudes de documentos del SDK Web, así como SDKs Entrust para flujos que contienen módulos web. Onfido Android & iOS SDKs no fueron impactados. Nos disculpamos por esta perturbación. Un postmortem detallado seguirá una vez que hayamos concluido nuestra investigación.
#### Summary On 1 September 2026, from 13:21 UTC to 13:45 UTC, users attempting document capture in the Web SDK were unable to end their session. Esto también se extendió al SDK de Entrust nativo para configuraciones que contienen módulos web. Native Onfido Android y iOS SDKs no fueron afectados. ## Root Causes Una actualización rutinaria a una imagen de contenedor para nuestro servicio de configuración de documentos introdujo una regresión al trabajo de sincronización que actualiza la lista de documentos. Esto resultó en el punto final que nuestros SDK utilizan para buscar documentos que devuelven errores de '500'. Esto impidió que los flujos de SDK web procedieran. Nuestros SDKs nativos utilizan una lista de documentos de copia de seguridad que les permitió continuar como normales. Nuestros despliegues progresivos están diseñados para capturar fallas de servicio antes de que sean significativas. Sin embargo, el fracaso laboral de la sincronización no marcó la sonda de preparación como insalubr, por lo que el despliegue continuó. ### Timeline 13:10 UTC: Comenzamos un despliegue progresivo del cambio. 13:21 UTC : El servicio se implementó completamente dando lugar a errores en la funcionalidad SDK impactada. 13:26 UTC: La vigilancia alertó al equipo. 13:44 UTC: Causa identificada y cambio volcado. 13:45 UTC: Servicio restaurado. ## Remedios * Agregaremos la cobertura de pruebas automatizadas desaparecidas para asegurarnos de que capturamos estos casos en el futuro. * Agregaremos una lista de documentos de retroceso al SDK Web, similar al mecanismo presente en los SDKs nativos, para asegurar que pueda funcionar en el caso de cualquier fallo futuro similar. * Arreglaremos el despliegue progresivo para asegurar que el despliegue no continúe en el caso de que algo haya ido mal con la sincronización de documentos.
Traducido automáticamente desde la actualización oficial del incidente.
Las caras conocidas que experimentan tasas de mayor consideración en todas las regiones.
## Summary El 26 de agosto de 2026, se observó un aumento en la tasa de consideración de caras conocidas durante el período comprendido entre las 15:00 y las 18:00 UTC. La tasa global observada de caras conocidas aumentó de ~6% a ~23% en todas las regiones. El aumento percibido puede haber sido mayor o menor, dependiendo de la geografía o vertical específica del cliente. El fue impulsado por un cambio a cómo se calculan las puntuaciones correspondientes a los partidos de Known Faces, que inflaron las puntuaciones para caras no palpadoras y causando así muchos informes para devolver partidos falsos y un resultado **consider**. ## Root Causes El cambio introdujo un nuevo algoritmo para marcar caras iguales, que está destinado a mejorar el rendimiento de memoria de caras conocidas. Esto fue ampliamente evaluado y validado por parámetros internos antes de ser liberado. Inadvertidamente, la transición de puntos de referencia a la producción no tuvo en cuenta parcialmente las características específicas del entorno de producción. En la raíz, una única constante no se convirtió correctamente en la transición, lo que resulta en un comportamiento equivocado del nuevo algoritmo de puntuación. ## Timeline 15:20 UTC: El cambio a caras conocidas es liberado 17:35 UTC: Aumento de la tasa de consideración en caras conocidas se nota. 17:50 UTC: El cambio se hace retroceder. Considere caídas de tarifas poco después. ## Remedios Estamos revisando los parámetros internos y los procedimientos de prueba que pueden aumentar la seguridad de este tipo de cambio. Específicamente, garantizar las pruebas internas refleja el panorama de producción real cuando se trata de conjuntos de datos y que las transiciones de parámetros y experimentos internos a la producción se prueban a fondo. Además, los procedimientos de cambio se llevarán a cabo con un control más estricto para que nos permita notar y actuar más rápido.
Traducido automáticamente desde la actualización oficial del incidente.
Semejanza Facial Las comprobaciones de movimiento que utilizan retos de azar están fallando a un ritmo mucho más alto de lo normal en la región de la UE.
## Summary El 24 de agosto de 2026, entre las 15:00 UTC y las 06:53 UTC a la mañana siguiente, los cheques de Moción de Similitud Facial con problemas de azar fallaron a un ritmo mucho más alto que lo normal en la región de la UE. Se aplicó una validación más estricta a todos los clientes de la región cuando debía haberse limitado a un solo cliente, lo que causaría que se rechazaran las verificaciones que de otro modo habrían pasado. Los informes afectados fueron devueltos con un fallo de " Autenticidad Visual". Debido a que los controles de Motion son totalmente automatizados, los usuarios finales detrás de estos informes fueron rechazados sin revisión manual, y algunos intentaron volver a comprobar y fueron rechazados por segunda vez. La tasa clara de estos cheques disminuyó de alrededor del 97% a alrededor del 54% para aproximadamente el 1.67% de los informes de Moción de Similitud Facial fueron afectados. Desactivar el cambio restaurado tasas normales claras inmediatamente. Otros controles de movimiento y otras regiones no fueron afectados. ## Root Causes Se estaba juzgando una validación más estricta del desafío de aleatoriedad de movimiento con un solo cliente, controlado por un ajuste de configuración per-clómero. Un error en nuestro código significaba que el ajuste se evaluó sin el identificador del cliente, por lo que la validación más estricta se aplicó a todos los clientes de la región de la UE ejecutando Motion con cheques de aleatoriedad en lugar de al indicado. Las comprobaciones que habrían pasado bajo la validación estándar fueron rechazadas y reportadas bajo el desglose de " Autenticidad Visual". Ninguna configuración del cliente o datos enviados fue culpado. ## Timeline Todas las veces UTC. * 24 de agosto, 15:00: habilitamos una validación más estricta para los desafíos de azar de movimiento en la región de la UE. Los cheques de movimiento usando aleatoriedad comenzaron a fallar a un ritmo mucho mayor. * 24 August, 16:36: a customer reported a drop in workflow success rates and we started investigating. * 25 agosto, 04:18: confirmamos la elevada tasa de fracaso y la escalamos. * 25 August, 06:53: revertimos el cambio y las tasas claras retornaron a la normalidad en cuestión de minutos. * 26 de agosto: implementamos una solución permanente. ## Remedios * Fortalecer los controles en torno a los cambios de configuración específicos del cliente para asegurar que no puedan aplicarse más ampliamente de lo previsto. * Mejorar el monitoreo y alerta para cheques de velocidad clara de Motion para que los cambios inesperados en las tasas de rechazo se detecten automáticamente y se escalan más rápidamente.
Traducido automáticamente desde la actualización oficial del incidente.
Actualmente estamos investigando retrasos en nuestro clúster estadounidense para el procesamiento de informes de la similitud facial, documentos y caras conocidas.
Estamos viendo el rendimiento degradado de algunos nodos en nuestro grupo de búsqueda de caras indexadas. Seguimos investigando la causa raíz y posibles remediaciones.
Hemos identificado la causa raíz del rendimiento degradado en nuestro grupo de búsqueda estadounidense y estamos trabajando activamente para resolverlo. Seguiremos de nuevo.
Implementamos una solución y seguimos monitoreando la calidad del tiempo de procesamiento, que ahora se mejora.
El tiempo de procesamiento sigue mejorando, todos los sistemas están en funcionamiento.
Los tiempos de procesamiento vuelven a la normalidad. Esta cuestión se resuelve ahora. Post-mortem a seguir pronto.
Traducido automáticamente desde la actualización oficial del incidente.
Identity Enhanced está experimentando una disminución importante de las tasas claras para los solicitantes todo el mundo excepto Reino Unido
Trabajamos con nuestro proveedor de terceros para resolver el problema y compartiremos las actualizaciones cuando estén disponibles.
Seguimos trabajando en una solución para esta cuestión.
Estamos viendo la recuperación de servicios de nuestro proveedor y solicitamos tasas de éxito mejorando. Seguimos vigilando de cerca la situación.
El proveedor ha resuelto el problema, y el servicio está funcionando normalmente
Traducido automáticamente desde la actualización oficial del 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.
