Onfido 장애 기록

1. 2026년 9월 7일 PM 3:53 UTCresolved

   14:30 및 15:30 UTC 사이, CA 지역의 고객들은 공개 API에 접근을 경험했습니다. 인증 레이어의 잘못된 배포는 유효 토큰을 잘못 거부, 실패한 API 요청에서 결과. 문제는 완전히 해결되었습니다. 행동은 끝에서 요구됩니다. 우리는 혼란에 대 한 사과.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 1일 PM 2:37 UTCresolved

   PM 1:21 PM UTC 에서 1:46 PM UTC, 웹 SDK에서 문서 요청을 수락하는 혼란뿐만 아니라 웹 모듈을 포함하는 흐름에 대한 Entrust IDV SDK. Onfido Android 및 iOS SDK는 영향을받지 않았습니다. 우리는이 혼란에 대해 사과합니다. 상세한 postmortem는 일단 우리가 우리의 조사를 결론을 내릴 것입니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 8일 PM 1:24 UTCresolved

   모든 지역에서 더 높은 고려율을 경험하는 Known Faces.

2. 2026년 9월 8일 PM 1:24 UTCpostmortem

   ## 요약 8월 26, 2026일, Known Faces의 상당한 비율이 15시와 18시 UTC 사이 기간 동안 관찰되었습니다. 전체 관찰 된 알려진 얼굴의 비율은 모든 지역에서 ~6%에서 ~23%로 증가했습니다. Perceived 증가는 클라이언트의 특정 지형 또는 수직에 따라서 더 높거나 낮출지도 모릅니다. 일치하는 점수가 비 매칭 얼굴에 대한 점수를 팽창하고 가짜 경기와 **consider** 결과를 반환하기 위해 많은 보고서를 유발하는 알려진 알려진 알록한 페이스 경기에 대해 계산되는 변경에 의해 구동되었습니다. ## 뿌리 원인 변화는 알려진 얼굴을 스코링하기위한 새로운 알고리즘을 도입했습니다. Known Faces recall 성능 향상을 목표로합니다. 이것은 풀어 놓기 전에 내부 벤치 마크에 의해 광대하게 평가되고 검증되었습니다. Inadvertently, 벤치 마크에서 생산 부분적으로 특정 생산 환경 특성에 대한 계정에 실패. 루트에서, 단일 상수는 전환에서 제대로 변환되지 않았고, 새로운 득점 알고리즘의 잘못된 행동으로 결과. ## 타임라인 15:20 UTC: 알록한 얼굴 변경은 풀어 놓습니다 17:35 UTC: Known Faces의 상당한 비율을 증가. 17:50 UTC: 변경은 다시 압 연. 다시 한번 떨어졌다. ## 구제 우리는 이 종류의 변화의 안전을 증가시킬 수있는 내부 벤치 마크 및 테스트 절차를 검토하고 있습니다. 특정하게, 내부 테스트를 지키는 데이터 세트에 관해서 실제 생산 풍경을 반영하고 내부 벤치 마크와 실험에서 생산까지의 전환은 완전히 테스트됩니다. 또한, 변경 절차는 더 단단한 감시로 실행될 것입니다 그래서 그것은 저희를 통지하고 빨리 행동할 수 있습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 8일 PM 1:17 UTCresolved

   임의의의 도전을 사용하여 얼굴의 유사성 운동은 EU 지역의 정상보다 훨씬 높은 속도로 실패합니다.

2. 2026년 9월 8일 PM 1:17 UTCpostmortem

   ## 요약 24 8 월 2026, 사이 15:00 UTC 과 06:53 UTC 다음 아침, 얼굴의 유사성 모션 체크를 사용하여 임의 도전은 EU 지역에서 정상적인보다 훨씬 높은 비율에 실패. 엄격한 검증은 단일 고객에 제한되어있을 때 지역의 모든 고객에게 적용됩니다. 그렇지 않으면 거부 된 검증을 유발합니다. 영향을받은 보고서는 "Visual Authenticity" 실패로 반환되었습니다. 모션 체크가 완전히 자동화되어 있기 때문에,이 보고서 뒤에 최종 사용자는 수동 검토없이 거부되었으며, 다시 체크를 시도하고 두 번째 시간을 거부했습니다. 이러한 검사에 대한 명확한 비율은 약 97 %에서 약 54%로 떨어졌습니다. 약 1.67%의 얼굴 유사성 운동 보고서가 영향을 받았다. 변경 복구된 정상적인 명확한 비율을 즉시 해제. 다른 모션 체크 및 다른 지역은 비범했다. ## 뿌리 원인 모션 임플란트 도전의 엄격한 검증은 단일 고객으로 평가되었으며, per-customer 설정에 의해 제어되었습니다. 우리의 코드의 버그는 설정이 고객 식별자없이 평가되었으므로 엄격한 검증은 의도 한 것보다 랜섬 체크와 EU 지역의 모든 고객에게 적용됩니다. 표준 유효성에 따라 통과 한 검증은 대신 거부되었으며 "Visual Authenticity"의 고장으로보고되었습니다. 고객 구성 또는 제출 된 데이터는 결함에있었습니다. ## 타임라인 모든 시간 UTC. * 24 8 월, 15:00 : 우리는 EU 지역의 모션 랜섬 문제에 대한 엄격한 검증을 가능하게합니다. 랜섬을 이용한 모션 체크는 훨씬 더 높은 비율로 실패했습니다. * 24 8 월, 16 : 36 : 고객은 워크 플로우의 성공률을보고 우리는 조사를 시작했다. * 25 8 월, 04 : 18 : 우리는 높은 실패율을 확인하고 그것을 에스컬레이션. * 25 8 월, 06 : 53 : 우리는 몇 분 안에 정상으로 변경 및 명확한 속도를 반전합니다. * 26 8 월 : 우리는 영구 수정을 배포했습니다. ## 구제 * 고객의 특정 구성 변화에 대한 제어를 강화하여 의도보다 더 넓은 적용 할 수 없습니다. * 모션 임플란트 투명 비율 검사에 대한 모니터링 및 경고를 개선하여 불량률의 예상치 못한 변화가 자동으로 감지되고 더 빠르게 확장됩니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 27일 PM 6:12 UTCinvestigating

   우리는 현재 우리의 미국 클러스터에 투자 지연은 얼굴 유사성, 문서 및 Known Faces 보고서의 처리를위한.

2. 2026년 7월 27일 PM 6:23 UTCinvestigating

   우리는 색인된 얼굴을 위한 우리의 검색 클러스터에 있는 몇몇 노드의 degraded 성과를 보고 있습니다. 우리는 뿌리 원인과 가능한 구제를 조사 계속합니다.

3. 2026년 7월 27일 PM 6:51 UTCidentified

   우리는 우리의 미국 검색 클러스터에 degraded 성과의 뿌리 원인을 확인하고 해결하기 위해 적극적으로 노력하고 있습니다. 한 번 완전히 복원됩니다.

4. 2026년 7월 27일 PM 7:18 UTCmonitoring

   우리는 수정을 구현하고 계속 처리 시간의 품질을 모니터링, 이는 이제 개선.

5. 2026년 7월 27일 PM 7:20 UTCmonitoring

   처리 시간은 개량하고, 모든 체계는 지금 가동입니다.

6. 2026년 7월 27일 PM 7:21 UTCresolved

   처리 시간은 정상에 뒤 입니다. 이 문제는 이제 해결되었습니다. 곧 따르는 포스트 mortem.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 24일 AM 4:18 UTCinvestigating

   영어 회화를 단기간에 완성하세요. 800 페이지가 넘는 레슨과 8000 개 이상의 오디오 클립을 다운로드 하시고, 자신을 영어 환경에 항상 노출 시키세요. 인터넷이나 컴퓨터에 상관없이 MP3 플레이어를 통해 언제나 영어를 듣고 따라할 수 있습니다. 영어회화 다운로드 페이지로 이동하시면 좀 더 자세한 내용을 알려드립니다

2. 2026년 7월 24일 AM 4:36 UTCidentified

   우리는 우리의 제 3 자 제공 업체와 협력하여 문제를 해결하고 그들이 가능한 한 업데이트 공유합니다.

3. 2026년 7월 24일 AM 4:55 UTCidentified

   이 문제를 해결하기 위해 계속 노력하고 있습니다.

4. 2026년 7월 24일 AM 5:09 UTCmonitoring

   우리는 우리의 공급자의 서비스 회복 및 요구 성공율을 개량하고 있습니다. 우리는 상황을 밀접하게 감시하기 위하여 계속합니다.

5. 2026년 7월 24일 AM 7:08 UTCresolved

   공급자는 문제점을 해결하고, 서비스는 지금 일반적으로 운영됩니다

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 23일 AM 2:38 UTCinvestigating

   We cannot complete QES tasks because our electronic signature provider is encountering issues.

2. 2026년 6월 23일 AM 2:57 UTCidentified

   Our provider is experiencing issues. All QES tasks cannot complete for now.

3. 2026년 6월 23일 AM 3:20 UTCidentified

   Our provider is still experiencing issues. All QES tasks cannot complete for now.

4. 2026년 6월 23일 AM 3:45 UTCmonitoring

   The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.

5. 2026년 6월 23일 AM 3:49 UTCresolved

   This incident has been resolved.

1. 2026년 6월 22일 PM 5:44 UTCmonitoring

   We're currently monitoring the EU cluster after an Amazon RDS issue.

2. 2026년 6월 22일 PM 5:56 UTCresolved

   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.

3. 2026년 7월 2일 PM 2:27 UTCpostmortem

   **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.

1. 2026년 6월 17일 AM 4:59 UTCidentified

   One of our providers is still experiencing issues, resulting in higher TaT for electronic signature tasks.

2. 2026년 6월 17일 AM 5:30 UTCidentified

   Our provider is actively working on fixing the issue.

3. 2026년 6월 17일 AM 6:19 UTCidentified

   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.

4. 2026년 6월 17일 AM 6:50 UTCidentified

   Our provider's error rate dropped significantly. The TaT of QES tasks is now close to the usual value.

5. 2026년 6월 17일 AM 8:17 UTCidentified

   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.

6. 2026년 6월 17일 AM 8:48 UTCmonitoring

   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.

7. 2026년 6월 17일 AM 9:23 UTCresolved

   The QES tasks TaT is back to normal.

1. 2026년 6월 16일 PM 10:19 UTCidentified

   Our electronic signature tasks are taking more time to complete because one of our providers is doing some maintenance.

2. 2026년 6월 16일 PM 10:52 UTCidentified

   Our provider is still not able to answer to all requests, resulting in longer-than-usual electronic signature task processing time.

3. 2026년 6월 16일 PM 11:17 UTCresolved

   The service is operational again.

1. 2026년 7월 13일 AM 8:39 UTCresolved

   Incident was solved.

2. 2026년 7월 13일 AM 8:40 UTCpostmortem

   ## 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.

1. 2026년 6월 6일 PM 2:08 UTCinvestigating

   Some Watchlist search search profiles are not working correctly the impacted reports are not being processed. We are investigation the root cause.

2. 2026년 6월 6일 PM 2:36 UTCidentified

   We identified the issue and are implementing a fix.

3. 2026년 6월 6일 PM 3:05 UTCmonitoring

   The issue has been fixed, and the reports are being processed correctly. We are still monitoring the service.

4. 2026년 6월 6일 PM 3:49 UTCresolved

   This incident has been resolved.

1. 2026년 5월 12일 PM 12:25 UTCidentified

   We are facing issues with one of our providers and we see a slight decrease in clear rate for Identity Reports in UK jurisdiction

2. 2026년 5월 12일 PM 12:55 UTCmonitoring

   A fix has been implemented and we are monitoring the results. All clear rates should be back to normal

3. 2026년 5월 12일 PM 1:14 UTCresolved

   All reports are back to normal.

1. 2026년 5월 9일 AM 11:27 UTCidentified

   We cannot complete QES tasks because our electronic signature provider is encountering issues.

2. 2026년 5월 9일 AM 11:27 UTCidentified

   The provider is working on a fix.

3. 2026년 5월 9일 AM 11:32 UTCmonitoring

   Our provider fixed the issue. QES tasks are completing now. Tasks started during the incident were resumed.

4. 2026년 5월 9일 PM 12:03 UTCresolved

   The service is operational, no error where detected after the fix.

1. 2026년 5월 5일 AM 6:52 UTCinvestigating

   We noticed an issue with our QES tasks, we're investigating.

2. 2026년 5월 5일 AM 6:56 UTCidentified

   Our provider is experiencing issues. All QES tasks cannot complete for now.

3. 2026년 5월 5일 AM 7:35 UTCidentified

   Our provider is fixing the issue. QES tasks still cannot complete.

4. 2026년 5월 5일 AM 8:04 UTCmonitoring

   The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.

5. 2026년 5월 5일 AM 8:39 UTCresolved

   QES is operational again.

1. 2026년 4월 21일 PM 2:56 UTCidentified

   We identified an issue with one of our provider and some QES tasks may encounter some problems.

2. 2026년 4월 21일 PM 3:14 UTCidentified

   Our provider is still experiencing issues. All QES tasks cannot complete for now.

3. 2026년 4월 21일 PM 4:12 UTCidentified

   Our provider continues experiencing issues and is working on a fix.

4. 2026년 4월 21일 PM 5:02 UTCidentified

   Our provider is slowly recovering, we expect some QES tasks to complete.

5. 2026년 4월 21일 PM 5:12 UTCresolved

   QES is operational again.

1. 2026년 2월 3일 AM 10:42 UTCidentified

   One of our provider is experiencing issues. QES capture tasks will fail and QES verification tasks will have an increase in TaT.

2. 2026년 2월 3일 AM 11:13 UTCidentified

   The provider is working on a fix, QES is still suffering a partial outage.

3. 2026년 2월 3일 AM 11:44 UTCidentified

   The provider is still working on a fix.

4. 2026년 2월 3일 PM 12:16 UTCidentified

   The provider is still working on a fix. QES verification tasks may start to time out, depending on their configuration, as we passed 90 minutes of downtime.

5. 2026년 2월 3일 PM 12:46 UTCmonitoring

   The provider fixed the issue. We can confirm our QES tasks are now processed correctly. We'll monitor the situation to make sure the error is indeed fixed.

6. 2026년 2월 3일 PM 1:16 UTCresolved

   We can confirm the error stopped and services are stable and operational.

1. 2026년 2월 2일 PM 3:36 UTCidentified

   We identified an issue with one of our provider and some QES tasks may encounter some problems.

2. 2026년 2월 2일 PM 4:15 UTCidentified

   Our provider is still experiencing issues. All QES tasks cannot complete for now.

3. 2026년 2월 2일 PM 4:46 UTCmonitoring

   Our provider is slowly recovering, we expect some QES tasks to complete.

4. 2026년 2월 2일 PM 5:18 UTCmonitoring

   We're now seeing the error rate decrease. Most of the QES tasks should complete.

5. 2026년 2월 2일 PM 5:24 UTCresolved

   QES is operational again.

1. 2026년 1월 28일 AM 11:16 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 1월 28일 AM 11:58 UTCmonitoring

   Issue found and fixed. Increased turn around time for manual reports. Estimated time to live manual processing is 4h.

3. 2026년 1월 28일 PM 3:22 UTCresolved

   Incident is fully resolved, manual processing is now working normally. Manual reports will keep having an increased turn around time for a few more hours while it works through the task backlog.

4. 2026년 2월 2일 PM 4:14 UTCpostmortem

   ### Summary Manual task assignment for all EU customers stopped working between 10h50 UTC and 11:50 UTC. This led to an increase in manual processing Turnaround Time \(TaT\) affecting approximately 20% of our document verification volumes with all customers recovering to TaT SLA by 18h00 UTC. During this period: * All checks that required **manual review** showed an increase in TaT. * **Fully automated reports were not affected** and continued to run as normal. The issue was caused by a **configuration error in our internal task management system**, which prevented it from correctly assigning tasks to our analysts. We fixed the configuration and **restored normal processing** by 28 Jan 2026 11h50 AM UTC, and cleared all manual task backlogs by 18h00 UTC. We have updated our validation and deployment checks to prevent similar issues in the future. ### Root Causes _Manual processing queue assignment was affected by an invalid manual configuration input. This single queue configuration parameter resulted in an error that affected assignments in all queues._ ### Timeline * all times in UTC: _10:50: Configuration manually updated and errors started, no more tasks assigned._ _11:02: On-call is notified of a spike in manual system assignment errors through our monitoring_ _11:07: The error responsible for the spike is identified \(invalid UUID\)_ _11:10: Incident declared_ _11:45: Origin of invalid UUID is found_ _11:50: Bad configuration parameter is deleted_ _11:56: Configuration reintroduced correctly_ _18:00: Recovered from manual task backlog_ ### Remedies * Adding appropriate input configuration value validation * Improve task assignment resilience to these types of errors * Review configuration guidance and post-release monitoring

1. 2026년 1월 26일 PM 12:46 UTCresolved

   Between 12:15 UTC and 12:40 UTC there was disruption to document report processing in EU. Autofill requests also saw a disruption between 12:16 UTC and 12:27 UTC. A postmortem will follow.

2. 2026년 1월 30일 AM 11:40 UTCpostmortem

   ## Summary On 26 January 2026 between 12.16 UTC and 12.35 UTC, our document reports processing was severely degraded with customers experiencing extended processing time to about 85% of their traffic. The incident also caused extended processing time on Biometric Authentications and Biometric Verifications for 20% of the traffic between 12.25 UTC and 12.35 UTC. ## Root Causes A core service for fraud prevention on documents came under elevated load, causing kubernetes pods to go down in quick sequence. Our upstream service retry policy proved too aggressive to let the service recover and required manual scaling-up. The retry policy also caused elevated load on a shared database which in turn also affected the biometrics service. ## Timeline * **12:16 UTC** – Our monitoring detected a sharp increase in errors when processing document reports. * **12:19** **UTC** – The on‑call team was alerted and began investigating the affected document‑processing service. * **12:25 UTC** – We identified that the incident was also affecting a small portion of biometric checks, leading to some failures and short delays. * **12:29** **UTC** – On-call engineers manually increased capacity for the impacted document fraud‑prevention service. * **12:35** **UTC** – Error rates for both document reports and biometric checks returned to normal and new requests were being processed successfully. * **12:45–13:06** **UTC** – We processed document reports that were impacted during the incident window. * **13:15** **UTC** – We confirmed that all affected document and biometric requests had completed successfully and marked the incident as resolved. ## Remedies * We have continued to fine-tune our auto-scaling parameters of the affected service to scale up with lower CPU targets. * We modified the retry policy of fraud services to avoid overloading an already struggling service so that it can auto-recover. * We made our load-tests on this service more representative of production traffic \(similar image sizes/document type distribution…\) and test for accelerated traffic spikes. * We lowered the total amount of shared database connections the document processing can take to avoid noisy neighbour impact on biometrics processing.