Is Onfido down?

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.

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 Document requests from the Web SDK. 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.

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.