Onfido の障害履歴

1. 2026年10月23日 1:22 UTCidentified

   英国の電子ビザのレポートとタスクは、当社のプロバイダの不足のために現在完了することはできません.

2. 2026年10月23日 1:47 UTCmonitoring

   プロバイダのサービスが復元され、英国の電子ビザは再び完了します.

3. 2026年10月23日 1:56 UTCresolved

   当社のサービスが再び運営されています.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月20日 6:23 UTCinvestigating

   当社のプロバイダーの1つは、いくつかのレポートの遅延を引き起こす問題があります。 課題を調査しています.

2. 2026年10月20日 7:05 UTCidentified

   プロバイダーは、まだ問題が発生しています。 状況をよく監視しています。 ID-UKは最もインパクトのあるサービスです.

3. 2026年10月20日 7:52 UTCidentified

   プロバイダーは問題を認識しています。 問題が解決次第、引き続きサービス再開準備をしております.

4. 2026年10月20日 8:55 UTCidentified

   当社のプロバイダは、積極的に取り組んでいるベンダーの1つで、主要なグローバル事件の影響を受けています.

5. 2026年10月20日 9:25 UTCmonitoring

   エラーは停止しました。 サービスを監視して、すべてが正常に戻っていることを確認してください.

6. 2026年10月20日 9:59 UTCresolved

   当社のサービスが再び運営されています.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月30日 10:55 UTCinvestigating

   私たちは、当社のプロバイダーとの問題に直面しています。また、英国の管轄区域で処理されていないアイデンティティレポートを参照してください

2. 2026年9月30日 11:20 UTCidentified

   問題は特定され、回避策を適用しました

3. 2026年9月30日 12:35 UTCmonitoring

   修正を実装し、結果を監視しています.

4. 2026年9月30日 12:37 UTCmonitoring

   今後の問題がないか引き続き監視しています。

5. 2026年9月30日 14:01 UTCresolved

   この事件は解決しました

公式のインシデント更新を自動翻訳しています。

1. 2026年9月22日 11:23 UTCidentified

   英国政府のサービスは、現在利用できません。 オンラインでサービスが戻って来るまで状況を監視しています.

2. 2026年9月22日 11:24 UTCidentified

   この問題の修正には引き続き取り組んでいます。

3. 2026年9月22日 11:40 UTCmonitoring

   サードパーティプロバイダは、今、オンラインで戻ってきます. チェックは処理されます。 状況を監視し続けます.

4. 2026年9月22日 11:49 UTCresolved

   サードパーティプロバイダは、オンラインに戻ります。 過去に立ち止まったチェックが処理されました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月7日 15:53 UTCresolved

   14:30～15:30 UTC の間、CA 地域の顧客はパブリック API へのアクセスを劣化させました。 認証層の不正な展開により、有効なトークンが誤って拒否され、失敗した API リクエストが発生した。 問題は完全に解決しました。 終了時にアクションは必要ありません。 わたしたちは、破壊のために報じています.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月1日 14:37 UTCresolved

   1:21 PM UTC から 1:46 PM UTC まで、Web SDK からのドキュメントリクエストの受け付けや、Web モジュールを含むフローの Entrust IDV SDK の受け入れが中断されました。 Onfido AndroidとiOS SDKは影響を受けません。 大変申し訳ございません。 調査を終えると、詳細な姿勢が追随します.

2. 2026年9月14日 9:18 UTCpostmortem

   #### 概要 2026年9月1日、13:21 UTCから13:45 UTCまで、Web SDKでドキュメントキャプチャをしようとするユーザーは、セッションを終了できませんでした。 また、Webモジュールを含む設定用のEntrust IDV SDKのネイティブ化にも拡張されます。 ネイティブ Onfido Android と iOS SDK が不備になりました。 ## ルート原因 ドキュメント設定サービスのコンテナイメージへの定期的な更新は、ドキュメントリストを更新する同期ジョブへの回帰を導入しました。 これにより、SDK が `500` エラーを返すドキュメントを fetch するために使用するエンドポイントが終了しました。 これにより、Web SDK が進行を防止しました。 ネイティブSDKは、バックアップ文書リストを使用しており、通常どおり継続できます。 当社のプログレッシブロールアウトは、彼らが重要になる前にサービス障害をキャッチするように設計されています。 しかし、同期ジョブの失敗は、読みやすさプローブを不健全にマークしなかったため、ロールアウトは継続しました。 ### タイムライン 13:10 UTC: 変化の進歩的なロールアウトを開始しました。 13:21 UTC : 本サービスは、影響を受けたSDK機能に関するエラーを完全にロールアウトしました。 13:26 UTC: チームを監視する。 13:44 UTCの: 原因を特定し、ロールバックを変更します。 13:45 UTC: サービス復元。 ### 救済 ※今後、これらのケースをキャッチする為に、欠落した自動テストカバレッジを追加いたします。 * ネイティブSDKに存在するメカニズムと同様に、フォールバックのドキュメントリストをWeb SDKに追加し、同様の将来の失敗の場合にはまだ機能できるようにします。 * 私達は何かが文書の同時性と間違っている場合のロールアウトが続行しないことを保障するために進歩的なロールアウトを修理します.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月8日 13:24 UTCresolved

   既知の顔は、すべての地域での料金を考慮します.

2. 2026年9月8日 13:24 UTCpostmortem

   ## 概要 2026年8月26日、15時から18時までの間、既知の顔の検討率が増加しました。 全体の観察率は、すべての地域全体で~6%から~23%に増加した既知の顔を考慮します。 クライアントの特定の地理や垂直に応じて、知覚の増加が高まり、下がっている可能性があります。 一致するスコアが既知の顔のマッチで計算される方法の変更によって駆動され、非一致の顔のスコアを膨脹させ、偽のマッチと**consider**の結果を返すために多くのレポートを引き起こしました。 ## ルート原因 変更は、既知の顔のリコール性能を向上させるために意図されているマッチング面のスコアリングのための新しいアルゴリズムを導入しました。 リリース前に内部のベンチマークで評価・検証を行いました。 その結果、ベンチマークから生産への移行は、特定の生産環境特性の考慮に部分的に失敗しました。 ルートでは、単一の定数がトランジションで正しく変換されず、新しいスコアリングアルゴリズムの誤った動作が発生しました。 ## タイムライン 15:20 UTC:既知の顔への変更がリリースされました 17:35 UTC: 既知の顔の率を考慮した増加が気づく. 17:50 UTC:変更はロールバックされます。 速度低下をすぐに考慮して下さい。 ## 救済 私たちは、この種の変更の安全性を高めることができる内部のベンチマークと試験手順を見直しています。 具体的には、内部のテストがデータセットに来ると内部のベンチマークや実験から生産への移行が徹底的にテストされると、実際の生産風景を反映していることを確認します。 また、変更手順はより早く通知し、行動できるように、より緊密な監視で行われます.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月8日 13:17 UTCresolved

   顔の類似性 ランダム性チャレンジを使用しての動作チェックは、EU地域の正常よりもはるかに高い速度で失敗しています.

2. 2026年9月8日 13:17 UTCpostmortem

   ## 概要 オン 24 8月 2026, 間に 15:00 UTC と 06:53 UTC 次の朝, 顔の類似性の動きは、EU地域の正常よりもはるかに高い速度で失敗したランダム性の問題を使用してチェック. 厳正な検証は、単一の顧客に限定されるべきである地域ですべての顧客に適用され、そうでなければ拒否されなければならない検証を引き起こしました。 「仮想正当性」障害で影響を受けたレポートが返されました。 モーションチェックが完全に自動化されるため、これらのレポートの背後にあるエンドユーザーはマニュアルレビューなしで拒否され、もう一度チェックを試み、秒間は拒否されました。 これらのチェックのクリアレートは、約97%から約54%に落ち、約1.67%の顔類似性モーションレポートの影響を受けました。 変更の復元された通常のクリアレートをすぐに無効にします。 ほかのモーションチェックや、他の地域は影響を受けません。 ## ルート原因 モーションのランダムネスチャレンジの厳密な検証は、顧客ごとに設定された単一の顧客と試用されています。 コードのバグは、顧客識別子なしで設定が評価されるため、意図されたものではなく、モーションを実行しているEU地域のすべての顧客に厳しい検証が適用されました。 標準的な検証に合格した検証は、代わりに拒否され、「仮想認証」の故障で報告されました。 顧客構成または提出されたデータは欠陥でなかった。 ## タイムライン UTC は、常に UTC です。 ※8月24日(水) 15:00: EU地域における動乱の課題に対する厳しい検証を行いました。 ランダム性を使用したモーションチェックは、はるかに高い速度で失敗し始めました。 * 8月24日、16:36:顧客はワークフローの成功率の低下を報告し、調査を開始しました。 ※8月25日、04.18:高機能障害率の確認とエスカレーションを行いました。 * 8 月 25 日、 06:53: 変更とクリアレートを数分以内に正常に戻しました。 * 8月26日:私達は永久的な修正を配りました。 ## 救済 * 顧客固有の構成変更の周りの制御を強化し、意図よりも広く適用できないようにします。 * 拒絶率の予期しない変化が自動的に検出され、より迅速にエスカレーションされるように、モーションランダムネスクリアレートの監視と警告を改善します.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月27日 18:12 UTCinvestigating

   現在、顔の類似性、文書および既知の顔のレポートの処理のための米国のクラスターの遅延を調査しています.

2. 2026年7月27日 18:23 UTCinvestigating

   インデックスされた面の検索クラスターで、一部のノードの劣化性能が確認されています。 根本原因を調査し、是正を可能とします.

3. 2026年7月27日 18:51 UTCidentified

   米国の検索クラスターで劣化した性能の根本原因を特定し、解決に積極的に取り組んでいます。 復旧完了後、フォローアップします.

4. 2026年7月27日 19:18 UTCmonitoring

   修正を実施し、処理時間の品質を監視し続けます.

5. 2026年7月27日 19:20 UTCmonitoring

   処理時間は改善し続けます。すべてのシステムが稼働しています.

6. 2026年7月27日 19:21 UTCresolved

   処理時間は正常に戻ります。 この問題は解決しました。 すぐに続くためにポスト・モリテム.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月24日 4:18 UTCinvestigating

   アイデンティティの強化は、英国を除いて、他のすべての世界の申請者に明確な料金の大きな減少を経験しています

2. 2026年7月24日 4:36 UTCidentified

   当社は、第三者のプロバイダと協力して、問題を解決し、アップデートを共有します.

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日 17:44 UTCmonitoring

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

2. 2026年6月22日 17: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日 14: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日 22: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日 22: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日 23: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日 14: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日 14:36 UTCidentified

   We identified the issue and are implementing a fix.

3. 2026年6月6日 15:05 UTCmonitoring

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

4. 2026年6月6日 15: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日 13: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日 14:56 UTCidentified

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

2. 2026年4月21日 15:14 UTCidentified

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

3. 2026年4月21日 16:12 UTCidentified

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

4. 2026年4月21日 17:02 UTCidentified

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

5. 2026年4月21日 17:12 UTCresolved

   QES is operational again.