Onfido outage history

We can't currently complete UK eVisa reports and tasks because of an outage of our provider.

The provider's services have been restored, our UK eVisas tasks are completing again.

Our services are operational again.

One of our provider is having issues, which will cause delays on some reports. We're investigating the issue.

Our provider is still experiencing issues. We're closely monitoring the situation. ID-UK is our most impacted service.

The provider is aware of the issue. We're still ready to resume our services as soon as the issue is solved.

Our provider is affected by a major global incident at one of its vendors, which is actively being worked on.

Errors stopped. We're monitoring our services to make sure everything is back to normal.

Our services are operational again.

We are facing issues with our providers and we see Identity Reports not being processed in UK jurisdiction

The issue has been identified and we applied a workaround

A fix has been implemented and we are monitoring the results.

We are continuing to monitor for any further issues.

This incident has been resolved

This UK Government service is currently down and not available. We are monitoring the situation until the service comes back online.

We are continuing to work on a fix for this issue.

3rd party provider appears to be back online now. Checks are being processed. Continuing to monitor the situation.

3rd party provider is back online. Checks previously stuck have been processed now.

Between 14:30 and 15:30 UTC, customers in the CA region experienced degraded access to the Public API. A faulty deployment in the authentication layer caused valid tokens to be incorrectly rejected, resulting in failed API requests. The issue has been fully resolved. No action is required on your end. We apologise for the disruption.

From approximately 1:21 PM UTC to 1:46 PM UTC, there was a disruption to accepting Document requests from the Web SDK as well as Entrust IDV SDKs for flows containing web modules. Onfido Android & iOS SDKs were not impacted. We apologize for this disruption. A detailed postmortem will follow once we've concluded our investigation.

### Summary On 1 September 2026, from 13:21 UTC to 13:45 UTC, users attempting document capture in the Web SDK were unable to finish their session. This also extended to native Entrust IDV SDK’s for configurations that contain web modules. Native Onfido Android and iOS SDKs were unaffected. ### Root Causes A routine update to a container image for our document configuration service introduced a regression to the synchronization job that updates the documents list. This resulted in the endpoint that our SDKs use to fetch documents returning `500` errors. This prevented web SDK flows from proceeding. Our native SDKs use a backup document list which allowed them to continue as normal. Our progressive roll-outs are designed to catch service faults before they become significant. However, the synchronization job failure did not mark the readiness probe as unhealthy, so the rollout continued. ### Timeline _13:10 UTC:_ We started a progressive rollout of the change. _13:21 UTC_: The service was fully rolled out leading to errors on impacted SDK functionality. _13:26 UTC:_ Monitoring alerted the team. _13:44 UTC:_ Cause identified and change rolled back. _13:45 UTC:_ Service restored. ### Remedies * We will add missing automated testing coverage to ensure that we catch these cases in the future. * We will add a fallback document list to the Web SDK, similar to the mechanism present in the native SDKs, to ensure it can still function in the case of any similar future failures. * We will fix the progressive rollout to ensure that the rollout will not continue in the case that something has gone wrong with synchronizing documents.

Known Faces experiencing higher consider rates across all regions.

## Summary On August 26, 2026, an increase in the consider rate of Known Faces was observed during the period between 15:00 and 18:00 UTC. The overall observed consider rate of Known Faces increased from ~6% to ~23% across all regions. Perceived increase may have been higher or lower, depending on the client’s specific geography or vertical. The was driven by a change to how matching scores are calculated for Known Faces matches, which inflated scores for non-matching faces and thus causing many reports to return false matches and a **consider** result. ## Root Causes The change introduced a new algorithm for scoring matching faces, which is intended to improve Known Faces recall performance. This was extensively evaluated and validated by internal benchmarks before being released. Inadvertently, the transition from benchmarks to production partially failed to account for particular production environment characteristics. At the root, a single constant wasn’t properly converted in the transition, resulting in wrong behavior of the new scoring algorithm. ## Timeline     15:20 UTC: Change to Known Faces is released     17:35 UTC: Increased consider rate on Known Faces is noticed.     17:50 UTC: Change is rolled back. Consider rate drops soon after. ## Remedies We are reviewing internal benchmarks and testing procedures which can increase the safety of this kind of change. Specifically, ensuring internal testing reflects the real production landscape when it comes to datasets and that transitions from internal benchmarks and experiments to production are thoroughly tested. In addition, change procedures will be carried out with tighter monitoring so it allows us to notice and act faster.

Facial Similarity Motion checks using randomness challenges are failing at a much higher rate than normal in the EU region.

## Summary On 24 August 2026, between 15:00 UTC and 06:53 UTC the following morning, Facial Similarity Motion checks using randomness challenges failed at a much higher rate than normal in the EU region. A stricter validation was applied to all customers in the region when it should have been limited to a single customer, causing verifications that would otherwise have passed to be rejected. Affected reports were returned with a "Visual Authenticity" failure. Because Motion checks are fully automated, the end users behind these reports were rejected with no manual review, and some attempted the check again and were rejected a second time. The clear rate for these checks fell from around 97% to around 54% for approximately 1.67% of Facial Similarity Motion reports were affected. Disabling the change restored normal clear rates immediately. Other Motion checks and other regions were unaffected. ## Root Causes A stricter validation of the motion randomness challenge was being trialled with a single customer, controlled by a per-customer configuration setting. A bug in our code meant the setting was evaluated without the customer identifier, so the stricter validation was applied to all customers in the EU region running Motion with randomness checks rather than to the intended one. Verifications that would have passed under the standard validation were rejected instead, and reported under the "Visual Authenticity" breakdown. No customer configuration or submitted data was at fault. ## Timeline All times UTC. * 24 August, 15:00: we enabled a stricter validation for motion randomness challenges in the EU region. Motion checks using randomness began failing at a much higher rate. * 24 August, 16:36: a customer reported a drop in workflow success rates and we began investigating. * 25 August, 04:18: we confirmed the elevated failure rate and escalated it. * 25 August, 06:53: we reverted the change and clear rates returned to normal within minutes. * 26 August: we deployed a permanent fix. ## Remedies * Strengthen the controls around customer-specific configuration changes to ensure they cannot be applied more broadly than intended. * Improve monitoring and alerting for Motion randomness clear rate checks so that unexpected changes in rejection rates are detected automatically and escalated more quickly.

We are currently investigating delays in our US cluster for the processing of Facial Similarity, Document and Known Faces reports.

We are seeing degraded performance of some nodes in our search cluster for indexed faces. We continue to investigate the root cause and possible remediations.

We've identified the root cause of degraded performance in our US search cluster and are actively working to resolve it. We'll follow up once fully restored.

We implemented a fix and continue to monitor the quality of processing time, which is now improved.

Processing time keeps improving, all systems are now operational.

Processing times are back to normal. This issue is now resolved. Post-mortem to follow soon.

Identity Enhanced is experiencing a major decrease in clear rates for applicants all other the world except UK

We are working with our third-party provider to resolve the issue and will share updates as they become available.

We are continuing to work on a fix for this issue.

We are seeing our provider's service recovery and request success rates improving. We continue to monitor the situation closely.

The provider has resolved the issue, and the service is now operating normally

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.