Onfido 장애 기록

1. 2026년 10월 23일 오전 1:22 UTCidentified

   우리는 현재 영국 eVisa 보고서를 완료하고 우리의 공급자의 부족 때문에 작업을 완료 할 수 없습니다.

2. 2026년 10월 23일 오전 1:47 UTCmonitoring

   공급자의 서비스는 복원되었습니다, 우리의 영국 eVisas 작업은 다시 완료됩니다.

3. 2026년 10월 23일 오전 1:56 UTCresolved

   우리의 서비스는 다시 가동됩니다.

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

1. 2026년 10월 20일 오전 6:23 UTCinvestigating

   우리의 공급자 중 하나는 문제, 어떤 보고서에 지연을 일으킬 것입니다. 우리는 문제점을 조사하고 있습니다.

2. 2026년 10월 20일 오전 7:05 UTCidentified

   우리의 공급자는 아직도 문제점을 경험하고 있습니다. 우리는 상황을 감시합니다. ID-UK는 우리의 가장 충격을 받는 서비스입니다.

3. 2026년 10월 20일 오전 7:52 UTCidentified

   공급자는 문제점의 aware입니다. 우리는 여전히 문제가 해결 된대로 우리의 서비스를 다시 시작할 준비가되어 있습니다.

4. 2026년 10월 20일 오전 8:55 UTCidentified

   우리의 공급자는 그것의 납품업자 중 하나에 있는 중요한 세계적인 사건에 의해, 적극적으로 일하고 있는.

5. 2026년 10월 20일 오전 9:25 UTCmonitoring

   오류가 중지되었습니다. 우리는 모든 것을 정상에 돌려보내는 우리의 서비스를 감시하고 있습니다.

6. 2026년 10월 20일 오전 9:59 UTCresolved

   우리의 서비스는 다시 가동됩니다.

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

1. 2026년 9월 30일 오전 10:55 UTCinvestigating

   우리는 우리의 공급자와 문제에 직면하고 있으며, Identity Reports는 영국 관할권에서 처리되지 않습니다

2. 2026년 9월 30일 오전 11:20 UTCidentified

   문제는 확인되고 우리는 workaround를 적용했습니다

3. 2026년 9월 30일 오후 12:35 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 9월 30일 오후 12:37 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

5. 2026년 9월 30일 오후 2:01 UTCresolved

   이 사건은 해결되었습니다

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

1. 2026년 9월 22일 오전 11:23 UTCidentified

   이 영국 정부 서비스는 현재 다운 및 사용할 수 없습니다. 우리는 서비스가 온라인에 돌아갈 때까지 상황을 모니터링하고 있습니다.

2. 2026년 9월 22일 오전 11:24 UTCidentified

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

3. 2026년 9월 22일 오전 11:40 UTCmonitoring

   제 3 자 제공 업체는 지금 다시 온라인이 나타납니다. 상품문의 상황을 모니터링.

4. 2026년 9월 22일 오전 11:49 UTCresolved

   제 3 자 제공 업체는 온라인입니다. 이전에 붙어 있던 체크는 지금 가공되었습니다.

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

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

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

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

1. 2026년 9월 1일 오후 2:37 UTCresolved

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

2. 2026년 9월 14일 오전 9:18 UTCpostmortem

   ### 요약 에 1 9월 2026, 부터 13:21 UTC 에 13:45 UTC, 웹 SDK에서 문서 캡처를 시도하는 사용자는 세션을 완료 할 수 없습니다. 또한 웹 모듈을 포함하는 구성에 대한 Native Entrust IDV SDK의 확장. Native Onfido Android 및 iOS SDK가 공개되었습니다. ## 뿌리 원인 문서 구성 서비스에 대한 컨테이너 이미지에 대한 일상적인 업데이트는 문서 목록을 업데이트하는 동기화 작업에 대한 회귀를 도입했습니다. 이 결과 엔드포인트에서 SDK는 `500` 오류를 반환하는 문서를 fetch로 사용합니다. 웹 SDK가 진행 중입니다. 우리의 네이티브 SDK는 정상으로 계속할 수 있는 백업 문서 목록을 사용합니다. 우리의 진보적인 롤아웃은 그들이 뜻깊은되기 전에 서비스 결함을 붙잡기 위하여 디자인됩니다. 그러나 동기화 작업 실패는 건강 한으로 읽지 않은 조사를 표시하지 않았다, 그래서 롤아웃 계속. ### 타임라인 13:10 UTC: 우리는 변화의 진보적인 롤아웃을 시작했습니다. 13:21 UTC : 이 서비스는 충격적인 SDK 기능에 대한 오류에 대해 완전히 출시되었습니다. 13:26 UTC: 감시는 팀을 경고했습니다. 13:44 UTC: 확인된 원인과 변화는 뒤를 구른다. 13:45 UTC: 서비스 복원. # # # # 치료 * 우리는 우리가 미래에 이러한 사례를 잡는 것을 보장하기 위해 누락 된 자동화 테스트 범위를 추가 할 것입니다. * 우리는 웹 SDK와 유사한 웹 SDK에 fallback 문서 목록을 추가합니다. 네이티브 SDK의 메커니즘과 유사하여 비슷한 미래의 실패의 경우 여전히 기능을 보장 할 수 있습니다. * 우리는 진보적 인 롤아웃을 수정하여 롤아웃이 문서 동기화로 잘못되었는 경우 계속되지 않습니다.

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

1. 2026년 9월 8일 오후 1:24 UTCresolved

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

2. 2026년 9월 8일 오후 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일 오후 1:17 UTCresolved

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

2. 2026년 9월 8일 오후 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일 오후 6:12 UTCinvestigating

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

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

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

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

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

4. 2026년 7월 27일 오후 7:18 UTCmonitoring

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

5. 2026년 7월 27일 오후 7:20 UTCmonitoring

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

6. 2026년 7월 27일 오후 7:21 UTCresolved

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

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

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

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

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

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

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

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

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

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

5. 2026년 7월 24일 오전 7:08 UTCresolved

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

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

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

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

2. 2026년 6월 23일 오전 2:57 UTCidentified

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

3. 2026년 6월 23일 오전 3:20 UTCidentified

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

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

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

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

   This incident has been resolved.

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

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

2. 2026년 6월 22일 오후 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일 오후 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일 오전 4:59 UTCidentified

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

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

   Our provider is actively working on fixing the issue.

3. 2026년 6월 17일 오전 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일 오전 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일 오전 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일 오전 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일 오전 9:23 UTCresolved

   The QES tasks TaT is back to normal.

1. 2026년 6월 16일 오후 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일 오후 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일 오후 11:17 UTCresolved

   The service is operational again.

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

   Incident was solved.

2. 2026년 7월 13일 오전 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일 오후 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일 오후 2:36 UTCidentified

   We identified the issue and are implementing a fix.

3. 2026년 6월 6일 오후 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일 오후 3:49 UTCresolved

   This incident has been resolved.

1. 2026년 5월 12일 오후 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일 오후 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일 오후 1:14 UTCresolved

   All reports are back to normal.

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

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

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

   The provider is working on a fix.

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

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

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

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

1. 2026년 5월 5일 오전 6:52 UTCinvestigating

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

2. 2026년 5월 5일 오전 6:56 UTCidentified

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

3. 2026년 5월 5일 오전 7:35 UTCidentified

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

4. 2026년 5월 5일 오전 8:04 UTCmonitoring

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

5. 2026년 5월 5일 오전 8:39 UTCresolved

   QES is operational again.

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

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

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

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

3. 2026년 4월 21일 오후 4:12 UTCidentified

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

4. 2026년 4월 21일 오후 5:02 UTCidentified

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

5. 2026년 4월 21일 오후 5:12 UTCresolved

   QES is operational again.