联合王国电子签证:延迟报告和任务
Issues轻微事件
受影响的组件
UK EVisa
- identified
我们目前无法完成英国eVisa的报告和任务 因为我们的供应商停业了.
- monitoring
供应商的服务已经恢复,联合王国的eVisas任务正在再次完成.
- resolved
我们的服务再次投入使用.
自动翻译自官方事件更新。
61 Onfido incidents · 2025年5月 — official updates, affected components, duration and resolution details.
我们目前无法完成英国eVisa的报告和任务 因为我们的供应商停业了.
供应商的服务已经恢复,联合王国的eVisas任务正在再次完成.
我们的服务再次投入使用.
自动翻译自官方事件更新。
我们的一个提供方有问题,这将导致某些报告的拖延。 我们正在调查这个问题.
我们的供应商仍然面临问题。 我们正在密切监视局势 ID -UK是我们最受影响的服务.
供养者已发觉. 问题解决后,我们仍然准备恢复服务.
我们的供应商受到其一家供应商重大全球事件的影响,目前正在积极开展工作.
错误已停止 。 我们正在监控我们的服务 确保一切恢复正常.
我们的服务再次投入使用.
自动翻译自官方事件更新。
我们正面临与供应商的问题,我们发现身份报告没有在联合王国管辖范围内处理
这个问题已经确定,我们做了一些研究
一项措施已经执行,我们正在监测结果.
我们正在继续监测任何其他问题.
这件事已经解决了
自动翻译自官方事件更新。
联合王国政府的这项服务目前已经减少,无法提供。 我们正在监测情况,直到服务恢复上网.
我们正在继续努力解决这个问题。
3晚会的供应商现在又在网上了 检查正在进行中。 继续监测局势.
三会提供商再上线. 之前卡住的检查已经处理完毕 .
自动翻译自官方事件更新。
UTC下午2点30分至3点30分,CA地区的顾客使用公共API的机会下降. 认证层中的错误部署导致有效符被错误地拒绝,导致API请求失败. 这个问题已完全解决。 你那边不需要采取行动 我们为干扰道歉.
自动翻译自官方事件更新。
从UTC下午1点21分左右到UTC下午1点46分,接受Web SDK的文件请求以及Entrust IDV SDK对包含web模块的流量的访问中断. Onfido Android & iOS SDKs没有受到影响. 我们对此感到抱歉。 一旦我们完成调查 详细尸检就会结束.
页:1 2026年9月1日,从协调世界时13:21到协调世界时13:45,试图在Web SDK中捕获文档的用户无法完成会话. 这也扩展到了本地 Entrust IDV SDK 的配置,用于包含网络模块的配置. 原生的Onfido Android和iOS SDK没有受到影响. * 根源 常规更新一个容器图像,用于我们的文件配置服务,为更新文档列表的同步任务引入了回归. 这导致了我们SDKs用来取回 " 500 " 错误的文件的终点。 这阻止了网络SDK的流量。 我们的本地SDK使用备份文档列表,允许它们继续正常运行. 我们的逐步推出旨在赶在服务缺陷变得显著之前抓住这些缺陷。 然而,同步工作失败并没有将准备状态探测仪标记为不健康,因此推出工作仍在继续. 时间线 13:10 UTC: 我们开始逐步推出变革。 13:21 UTC : (中文(简体) ). 该服务被全面推出,导致受影响的SDK功能出错. 13:26 世界协调时: 监测使小组警觉。 13:44 UTC: 原因已经查明,变化已经回滚。 13:45 UTC: 服务恢复。 补救 * 我们将增加缺失的自动测试覆盖面,以确保今后能够接获这些案件。 *我们将在Web SDK中添加一个倒置的文档列表,类似于原生SDK中存在的机制,以确保它在未来出现任何类似故障时仍能运行. * 我们将确定逐步推出,以确保在文件同步出现问题的情况下,推出工作不会继续下去.
自动翻译自官方事件更新。
已知各区域考虑率较高的面孔.
□ 总结 2026年8月26日,在协调世界时(UTC)下午3:00至6:00期间观察到"知相"的考虑率有所上升. 在所有区域,观察到的已知面孔的总体考虑率从6%增至23%。 根据客户的具体地理或垂直情况,预期的增长可能更高或更低。 之所以出现这种情况,是因为对已知面相匹配的相匹配分数的计算方式有所改变,从而夸大了非相匹配面相的相匹配分数,从而导致多份报告回回了假相匹配并得出了**考虑**结果. □ 根源 修改引入了新的评分相配面相的算法,意在改进"知相"的回想性能. 在发布之前,内部基准已对此进行了广泛的评估和验证。 不可否认的是,从基准向生产过渡部分未能考虑到特定生产环境特点。 在根本上, 一个单一的常数在转换过程中没有被正确转换, □ 时间线 15:20 UTC: 更改为已知面相发布 17:35 UTC:注意到已知面孔的考虑率提高。 17:50 UTC:更改回滚. 考虑速率会很快下降 □ 补救措施 我们正在审查能够加强这种变化的安全的内部基准和测试程序。 具体而言,确保内部测试在数据集方面反映真实的生产情况,并确保从内部基准和实验向生产过渡得到彻底测试。 此外,改革程序将在更严格的监测下进行,以便使我们能够注意到并加快行动.
自动翻译自官方事件更新。
利用随机性挑战的相类似性运动检查在欧盟地区以比平时高得多的速度失败.
□ 总结 2026年8月24日,在协调世界时下午3:00至次日上午06:53之间,利用随机性挑战的Facial相似性运动检查以比欧盟地区正常得多的速度失败. 对该区域所有客户都采用了更严格的验证办法,当时应仅限于单一客户,导致本来会过去的核查被拒绝。 受影响报告以"视觉真实性"故障发回. 由于动作检查是完全自动化的,这些报告背后的终端用户在没有人工审查的情况下被拒绝,有些人再次尝试检查,第二次被拒绝. 在大约1.67%的 " 相似性运动 " 报告中,这些检查的清晰率从97%左右下降到54%左右。 使变化失效,立即恢复了正常的明确费率。 其他动议检查和其他地区没有受到影响。 □ 根源 对移动随机性挑战进行更严格的验证,由一个客户进行试验,由每个客户的配置来控制。 我们代码中的一个错误意味着设置是在没有客户身份标识的情况下被评估的,因此更严格的验证被应用于运行随机性检查的欧盟区域所有客户,而不是预定的客户. 本来会在标准验证下通过的核查被否决,并在"视觉真实性"分解下报告. 没有客户配置或提交的数据有问题。 □ 时间线 所有时间UTC. * 8月24日,下午3:00:我们对欧盟区域的运动随机性挑战进行了更严格的验证。 使用随机性进行的动议检查开始以更高的速度失败. * 8月24日,16:36:一个客户报告工作流程成功率下降,我们开始进行调查。 * 8月25日,04:18:我们确认故障率上升并升级。 * 8月25日,06:53:我们在几分钟内恢复了变化和明确费率恢复正常。 * 8月26日:我们部署了一个永久固定装置。 □ 补救措施 * 加强针对客户的配置改变的控制,以确保这些改变不能被比预期的更广泛应用。 * 改进对动机随机性明细率检查的监测和警报,以便自动发现拒绝率的出乎意料的变化并更快地升级.
自动翻译自官方事件更新。
我们目前正在调查美国小组在处理类似面相、文件和已知面相报告方面的延误.
我们正看到一些节点在搜索指数化面孔的集群中性能下降。 我们继续调查根源和可能的补救.
我们在我们的美国搜索集群中找出了退化性能的根本原因,并正在积极努力解决这个问题. 完全恢复后再跟进.
我们执行了一项固定措施,并继续监测处理时间的质量,现已改进.
处理时间不断缩短,所有系统现已投入使用.
处理时间恢复正常. 这个问题现已得到解决。 死后随从.
自动翻译自官方事件更新。
除联合王国外,全世界所有申请人身份强化率明显下降
我们正在同我们的第三方提供者合作来解决这一问题,并将在获得最新情况后分享.
我们正在继续努力解决这个问题。
我们正看到供应商恢复服务,要求提高成功率。 我们继续密切监测局势.
供应商已经解决了这个问题,服务现已正常运行
自动翻译自官方事件更新。
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.