Unico の障害履歴

1. 2026年8月30日 2:35 UTCinvestigating

   顧客を遅らせて下さい、 2026年8月29日(金)午後11時頃に、IDCloudでプロセス作成に影響を及ぼす可能性を特定しました。 この期間中、通常の応答時間よりも遅くても、リクエストが失敗したり、遅くなったりすることもあります。 ご迷惑をおかけしますが、ご理解のほどよろしくお願い申し上げます。 アップデートが短時間で提供されます。 ユニコチーム

2. 2026年8月30日 2:49 UTCidentified

   エンジニアリングチームは、IDCloudでプロセス作成に影響を与える不安定性の起源をマッピングしました。 技術的なチームは、影響を受けた層のリソースをスケーリングし、キーインジケータを継続的に監視するなど、是正措置を適用し始めています。 本サービスの復元は、最優先かつフルエンジニアリングの動員で処理されます。 アップデートを短時間でお届けいたします。 ユニコチーム

3. 2026年8月30日 2:57 UTCmonitoring

   顧客を遅らせて下さい、 当社のエンジニアリングチームは、IDCloudでプロセス作成に影響を及ぼす可能性を解決するために必要な是正措置を実施しました。 環境は安定性に戻ってきました, 可用性と応答時間インジケータは、通常の動作レベルに復元しました 11:48 PM (BRT). 本サービスは通常の利用にご利用いただけます。 現時点では、当社の技術チームは、サポートされた監視のもと、一貫性のあるパフォーマンスを確保し、任意の変動の場合にはすぐに行動するために、環境を密接に監視しています。 今後、より一層の更新が行われることをご理解いただき、ご了承賜りますようお願い申し上げます。 ユニコチーム

4. 2026年8月30日 3:15 UTCresolved

   顧客を遅らせて下さい、 エグゼクティブサマリーとインパクト 2026年8月29日、午後11時48分(BRT)の間、IDCloudで発生した処理不足が発生しました。 このウィンドウでは、これらのフローを使用して一部の顧客は、認証、ドキュメントキャプチャ、通知配信を含む依存する旅への伝播と、経験豊富な障害と応答時間を増加させました。 処理された情報の完全性やセキュリティに妥協せず、データの紛失はありませんでした。 11:48 PM (BRT) で正常な動作レベルに戻ってインジケーター, 正規化は、私たちの監視と顧客側の両方を確認しました, プロセスの作成と完了をカバー. 根本原因と決議 原点はデータレイヤーで特定されました。内部メンテナンスのルーチンが立ち往生し、利用可能な接続制限が疲れ、処理能力を削減するまで、アプリケーション操作がそれの背後押しを開始しました。 私たちのエンジニアリングチームは、手術的には立ち止まったルーチンだけを終了し、すぐにキューを解放します。 接続と処理能力は完全に復元され、データの変更はありません。 コミットメントと次のステップ 当社のエンジニアリングチームは、内部メンテナンスルーチンの待ち時間を制限し、同時に実行から同時ルーチンを防ぎ、データレイヤーの変動に対するサービスレジリエンスを強化します。 完全なタイムラインと期限付きのアクションプランを含む詳細な郵便物は、すぐに共有されます。 皆様のお越しを心よりお詫び申し上げます。 ユニコチーム

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

1. 2026年8月10日 20:26 UTCidentified

   親愛なる顧客, 弊社では、Behavior Alert(IDTrust)機能および1:N フローに影響を及ぼす、IDCloud のリクエストに影響を検知しました。 この不安定性は、この機能を使用するメキシコの顧客にも影響を及ぼす可能性があります。 当社のエンジニアリングチームは、できるだけ早く問題を解決するために動員されます。 新しいアップデートを短時間で提供いたします.

2. 2026年8月10日 20:29 UTCmonitoring

   当社のエンジニアリングチームは、影響を受けるIDCloudフロー機能の不安定性を解決するために必要な行動を特定し、実施しました。 今回、当社のデータレイヤーの詳細な解析を行い、環境を監視し続けています。 アップデートを短時間でお届けいたします.

3. 2026年8月10日 21:01 UTCresolved

   エグゼクティブサマリーとインパクト 午後5時08分頃、自動アラートは顔認証サービス(1:Nフロー)の可用性低下を検出し、インシデントをトリガーします。 問題は迅速にエスカレーションし、行動アラートサービスに影響を及ぼし始め、その後、プロセス作成フローは、これらのサービス間でタイムアウトをカスケーディングするからです。 これらの機能を使用してクライアントのサブセットに影響される影響。 状況は午後5時22分に安定化され、メトリックは通常のレベルに戻りました。 根本原因と決議 根本原因は、内部のワークロードによって生成されたトラフィックのスパイクでした。これは、通常のクライアントトラフィックによって使用されるエッジ層を迂回し、顔認識リクエストの大量をバイオメトリックパイプラインに直接送信しました。 この追加ボリュームは、顔認識サービスをサポートするデータベースの容量を飽和させました。 飽和は、そのサービスでタイムアウトを引き起こし、バイオメトリックエンジンのオーケストレーションサービスにカスケードされ、その後、行動アラートサービス、およびこれらの機能を使用してプロセス作成フローに最終的にを引き起こしました。 問題の解決のために、チームは、スパイクの責任ある作業負荷を止め、影響を受けたデータベースの容量を増加させました。 これらのアクションは、問題を軽減し、エラーのボリュームがほぼゼロレベルに戻ります。 コミットメントと次のステップ フォローアップアイテムは、スパイクを引き起こした内部のワークロードのタイプに対して、再発に対する予防策として制限率を実装するために開いていました。 影響を受けたデータベースの容量は、インシデント自体で既に実施されていました.

4. 2026年8月25日 13:05 UTCpostmortem

   **概要** 2026年8月10日、午後5時08分から午後5時27分までの間、1日の顔認識フローが95%下落し、約19分の影響を受けます。 インシデントは、バイオメトリクスエンジンによって使用されるベクター検索データベースの飽和によって引き起こされ、キュー消費メカニズムの予期しない動作に起因し、これにより、呼び出し量を2.36倍増しました。 過剰な負荷は、データベースの最大のスケーリング限界に達し、複数の依存サービスを渡るカスケードタイムアウトを引き起こし、期間中に55のクライアントユーザーに影響を与える。 **インパクト** 顔認証、認証、プロセス作成のユーザーは、複数のクライアントからエラーやタイムアウトを経験した期間から流れます。 バイオメトリックオーケストレーション、エンジン、プロセス作成サービスによるデータベース飽和カスケード 内部サービスを解散し、データベースの最大のスケーリング限界を増加させることで、サービスの安定化を午後5時27分に完了しました。 **ルート原因** 根本的な原因は、サービスの行動と関与するインフラの能力に関連する要因の組み合わせでした。 本サービスは、毎秒2つのリクエストの制限で構成されていましたが、キュー消費メカニズムは予期しないと振る舞います。処理が確認された期限を超えたメッセージは、元の実行をキャンセルすることなくキューによって再配列され、938の作業項目を2,217の有効な呼び出し\(~8.4 RPS\)に変えました。 この増幅されたトラフィックは、このフローで使用されるネットワークパスがそれらの制御を通過しなかったので、通常、要求量を制限するエッジ保護レイヤーを通過することなくデータベースに到達しました。 データベースは、既に最大スケーリング限界に近い操作で、追加の負荷を吸収できませんでした。CPUは、100ノードの構成された天井までスケーリングしながら88%に達しました。クエリレイテンシは、p90で3秒〜18.75秒にジャンプし、依存サービスのチェーン全体にわたってタイムアウトを伝播しました。 **決断** チームは、アラートの数分以内に負荷のソースとして問題のプロセスを識別しました。 プロセスが無効化され、データベースの最大スケーリング制限が100～150ノードに増加しました。 これらの2つのアクションで、サービスが5:27 PMで安定化しました。 **レッスン内容** 消費者が再配達を通して容積を増幅することができるとき、インシデントは、メッセージの公開側にのみ適用される率の制限が不十分であることを示しました。 レートと並列制御は、消費側に存在する必要があります。 さらに、エッジ保護を迂回するパスを通して重要なコンポーネントにアクセスする内部サービスは構造的リスクを表しています。内部クライアントは、共有インフラストラクチャで制御されていない負荷を生成することができます.

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

1. 2026年7月31日 12:42 UTCinvestigating

   Prezados クライアント, Identificamos uma instabilidade técnica pontual que afeta a atualização do painel de acompanhamento o envio de documentos. Reforçamos que o fluxo de envio e assinatura está funcionando normalmente: os destinatários continuam recebendo e conseguindo assinar os arquivos. アンタント、oレジストはenvio podetemporariamente nãoser exibido na lista de acompanhamentoはremetenteを行います。 Nossa equipe de engenharia já está atuando para corrigir a exibição na インターフェイス eabelecer o histórico no 痛み o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos formados sobre o Progresso. アテンシオサメンテ,

2. 2026年7月31日 13:08 UTCidentified

   Prezados クライアント, Gostaríamos de atualizar o ステータス sobre a visualização de documentos no painel de acompanhamento. O 問題の foi identificado com sucesso por nossa equipe técnica. モーメントなし, os engenheiros já estão subindo a correção para restabelecer a exibição correta de todos os envios na インターフェイス remetente. Lembramos que o processamento, envio e assinatura dos documentos continuam オペランド normalmente. Volataremos com uma nova atualização assim que a correção のために concluída e entrarmos na fase de Monitoramento. アテンシオサメンテ,

3. 2026年7月31日 13:20 UTCmonitoring

   Prezados クライアント, Informamos que a correção para a exibição no painel de acompanhamento foi aplicada com sucesso. リストア·デ·ド·ド·ド·ド·ド·デ·envios já está retornando ànormalidade. モーメントなし, ノッサ・エキペ・デ・エンゲンハリア・モニターアンド・オ・アンビエンテ・デ・ペルト・パラ・ガーランティーア・エスタビッド・トータル・ド・サビティソ. Agradecemos a paciência e traremos a checkação do encerramento em breve. アテンシオサメンテ,

4. 2026年7月31日 14:06 UTCresolved

   Prezados クライアント, Informamos que o インシデント relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após aplicação da correção e o período de Monitoramento, checkamos que listagem e o histórico de documentos foram 合計mente restabelecidos, e plataforma オペラ em completa estabilidade. Agradecemos pela compreensão e paciência de todos durante o processo. アテンシオサメンテ,

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

1. 2026年7月29日 14:04 UTCresolved

   エグゼクティブサマリー&インパクト ID Cloud Webhook 通知サービスに一時的に影響を及ぼすインシデントに通知したいと思います。 影響の期間: 08:32 から 10:05. プラットフォームの影響: 不安定性は、Webhook通知配信に厳密に制限され、メッセージ配信の遅延が発生しました。 メインプラットフォームの劣化がなく、ライブエンジンの故障がなく、データ損失もありません。 顧客の影響:問題は顧客の小さい部分に影響を与えました。 GET ポーリングフローをコンポジション(フォールバック)として実装したクライアントは、ダウンタイムや運用上の影響を経験していません。 根本原因と決議 根本原因:環境の機能更新によって不安定性が引き起こされました。 タスクキューと送信先のルートの間のアクセス権限の一時的な不一致は、通知の一時的なバックログにつながる、拒否されるリクエストを引き起こしました。 解決的な行為: 技術的なチームは、新しい環境へのトラフィックリダイレクトを完了し、コンポーネント間の適切な通信を復元し、Webhookのバックログを解放します。 処理は正常に戻り、ディスパッチキューが完全にクリアされています。 コミットメントと次のステップ 当社のサービスの安定性は最優先事項です。 総透明性を確保し、再発防止のために、当社のエンジニアリングチームは次のフロントに焦点を合わせます。 詳細な郵便物: 詳細な根本原因分析と予防措置計画を備えた包括的なレポートが準備されます。 観察性の改善: 監視メトリクスを調整し、トランジションのシナリオ中にサービス間通信エラーに大きな視認性を確保します。 誠に申し訳ございませんが、ご不便をおかけいたしますが、ご理解のほどよろしくお願い申し上げます。 ユニコチーム

2. 2026年8月7日 13:08 UTCpostmortem

   **概要** 2026年7月29日、午前8時32分～午前10時05分の間、webhook配信サービスが約1時間33分劣化しました。 インシデントは、一時的な互換性状態を作成した計画されたインフラストラクチャの移行によって引き起こされました。内部のルートが新しいクラスターに切り替えた後、Webhookサービスは新しいクラスターから認証トークンを生成し始めましたが、配送はまだ古いクラスターに向けられていました。これにより、承認エラーでトークンを拒否しました。 失われたイベントは、需要に応じて再処理されました。 **インパクト** 認証、支払い、およびオンボーディングフローを含む複数の製品が同時に影響されました。 Webhook 通知のみに依存しているクライアントのユーザーは、期間中に経験豊富な業務中断を継続します。 フォールバック機構としてアクティブポーリングを実施したクライアントは、衝撃を低減しました。 **ルート原因** 根本的な原因は、移行計画で特定されました: 手順は、Webhookフローのチェーン依存性をマップしませんでした。内部のルートが非同期のタスクを生成し、順番に、公開ルートを呼び出します。 内部のルートと別の手順で公開ルートを移行することにより、新しいクラスターによって生成されたトークンが古いクラスターの認可ポリシーによって拒否されたところで、非互換性ウィンドウが作成され、以前のサービスアカウント識別子を具体的に検証しました。 このシナリオは、変更のリスクアセスメント中に特定されず、既存のサービス品質インジケーターのどれも、失敗が材料化した非同期配送レイヤーをカバーしていました。 **決断** チームは、障害の発生源としてトークンの不適合性を識別し、新しいクラスターに公開ルートの移行を完了し、発散を排除しました。 その点から、キュー内の保留中の配送は通常処理を開始した。 10:05に及ぶ影響が止まり、古いクラスターのトラフィックが10:32にゼロに達しました。 **レッスン内容** インシデントは、チェーンの非同期配送フローを含むマイグレーションは、チェーンに関与するすべてのルートを必要とすることを示しています — 内部と公開 — 調整された方法で移行されるため、クラスター間の互換性のないウィンドウなしで。 ほとんどのマイグレーションに適したグラデーションアプローチは、原子トランジションやより短いトランジションウィンドウで回避できる長期の故障期間を作成しました。 また、非同期配送層での保守性の欠如は、事件が内部的に検出されていない理由でした。既存の指標は、イベントの受諾だけを測定しました。実際の配達ではありません。 このレイヤーで失敗やバックログのための専用のアラートを作成することは、最も緊急な監視改善が特定されています.

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

1. 2026年7月24日 21:47 UTCinvestigating

   顧客を遅らせて下さい、 現在、データデリバリーにおける遅延に影響を及ぼすWebhooksの不安定性を調査しています。 当社のエンジニアリングチームは、可能な限り迅速に問題を解決するために積極的に取り組んでいます。 アップデートを短時間で提供いたします.

2. 2026年7月24日 21:53 UTCmonitoring

   顧客を遅らせて下さい、 当社のエンジニアリングチームは、データデリバリーレイテンシに影響を与えるWebhookの不安定性を解決するために必要なアクションを特定し、実施しました。 今回、当社のデータレイヤーの詳細な解析を行い、環境を監視し続けています。 アップデートを短時間でお届けいたします.

3. 2026年7月24日 22:18 UTCresolved

   エグゼクティブサマリーとインパクト Webhookサービスでは、6:05 PM(Brasília time)で開始し、イベント処理の失敗と、この期間中に影響を受ける操作の通知の配信につながります。 根本原因と決議 インシデントは、複数のサービスで使用されている共有サービスアカウントの問題によって引き起こされ、認証障害が発生しました。 根本原因を特定すると、エンジニアリングチームは必要な資格情報と構成を復元しました。 6:29 PM (BRT) では、通常の動作が完全に再確立されました。 コミットメントと次のステップ 継続的な改善とリスク軽減の一環として、エンジニアリングチームは、サービス全体でリソースの依存性とアクセス管理を見直します。 今後のインフラの調整に類似した構成の問題を防ぐことができます.

4. 2026年8月3日 20:00 UTCpostmortem

   **概要** 2026年7月24日、午後6時05分から午後6時29分までの間、webhook作成と配送サービスが利用できなくなった。 リソースの解凍プロセス中にインフラサービスアカウントへのアクセスの損失は、クラスターの移行につながりました。 影響を受けたアカウントは、この依存性が文書化されていない複数のサービスによって共有され、Webhookサービスは認証機能を失うことを防ぎ、イベントの作成と配信を停止します。 **インパクト** Webhookイベント作成と配信は、記録された1,550以上のエラーで18人のクライアントユーザーに影響を与える期間に中断されました。 同じ認証フローに依存する他のサービスにカスケードされたインパクトは、異なるプラットフォーム機能間で同時劣化を引き起こします。 **ルート原因** 根本的な原因は、サービス依存性の設定で識別されました。 このクロスサービスの依存性は、いかなる依存関係マッピングでも文書化も表示されていない。 廃止プロセスが元のサービスのリソースのクリーンアップの一部としてアカウントを削除した場合、アカウントが他のアクティブなサービスによって使用されていたかどうかを確認する自動化検証はありませんでした。 このセーフガードの欠如は、その除去が広範な認証障害を引き起こすまで、その依存性を隠しました。 **決断** チームは、認証失敗のソースとして、不安定なサービスアカウントを迅速に特定しました。 アカウントは手動で調整され、クラスターに適用され、6:29 PMでサービスを復元する。 衝撃時間は約24分です。 **レッスン内容** インシデントは、サービスの隠れた依存関係を作成するレガシー構成のリスクを明らかにしました。計画されたメンテナンス中に単一のリソース変更が複数のサービスを同時に混乱させるのに十分でした。 インフラストラクチャリソースの解凍プロセスは、変更前に自動依存性検証を含む必要があります.

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

1. 2026年7月21日 16:39 UTCidentified

   親愛なる顧客, プロセス・ジャーニーの認証フローに影響を及ぼすIDCloud機能の不安定性を調査し、特にWebジャーニー(旧ByUnico)に影響を及ぼす。 当社のエンジニアリングチームは、できるだけ早く問題を解決するために動員されます。 アップデートを短時間で提供いたします.

2. 2026年7月21日 16:49 UTCmonitoring

   顧客を遅らせて下さい、 当社のエンジニアリングチームは、影響を受けるIDCloudフロー機能の不安定性を解決するために必要な行動を特定し、実施しました。 今回、当社のデータレイヤーの詳細な解析を行い、環境を監視し続けています。 アップデートを短時間でお届けいたします.

3. 2026年7月21日 18:02 UTCresolved

   エグゼクティブサマリーとインパクト 2026年7月21日に約12:44 PM(Brasília time)で始まると、減ったオンボーディング・ジャーニーの一部が流れの初期画面の読み込みが遅くなる。 影響は、この旅が使用されるすべての環境全体で観察され、知覚速度に影響し、より少ない範囲で、この期間の間にプロセスを完了するユーザーの能力。 根本原因と決議 事件の決定的な根本原因を確認するため、調査は進行中です。 サーバ、ネットワーク、インフラに影響がなかったため、ユーザーのデバイスで画面上のエクスペリエンスに分離する問題が確認されました。 封入測定として、責任あるチームは1:39 PM(BRT)で予防調整を行い、数分以内に通常に戻りました。 根本原因を検証・確認するための分析は、依然として技術チームによって行われます。 コミットメントと次のステップ インシデント応答プロセスの継続的な改善の一環として、チームは、インシデントが開いた瞬間から、より直接かつ効果的に活性化する、責任あるチームのための自動エスカレーションフローを強化するためにコミットします。 また、この旅への新しい変更のロールアウト中にロード速度監視が強化され、潜在的な回帰の特定と修正の目標は、同様の状況でユーザーへの影響を最小限に抑え、より速くなります.

4. 2026年8月3日 14:01 UTCpostmortem

   **概要** 2026年7月21日、午後12時44分から午後1時43分までの間、ページロードパフォーマンスインジケーターが大幅に低下し、平均負荷時間が約4.8秒から〜8.9秒、p95が31.5秒に達します。 プロバイダーからの接続にクラウドインフラが適用されるレート制限により、フロントエンドアセットがロードされるのを防ぎました。 **インパクト** 32 人の顧客からのユーザーは、記録された約 94 の旅の間違いと非常に遅いページの負荷か完全なローディングの失敗を経験しました。 "初期化タイムアウト" エラー — アプリケーションが 30 秒以内にマウント失敗したときにトリガーされた — 期間中に約 23 万件の発生に達しました。 **ルート原因** ルート原因は、インフラのネットワーク層で特定されました。CDNプロバイダは、アウトバウンドIPアドレスの限られたセットを介してトラフィックを統合します。 これらのIPから発信する新しいTCP接続とTLSハンドシェイクのスパイクは、クラウドインフラストラクチャの自動ネットワークレイヤーの防衛メカニズムをトリガーし、HTTP処理の前の接続速度制限を開始しました。 これらの障害は、HTTP処理前にネットワークレイヤーで発生したため、標準の要求ログに表示されなかったため、従来の監視に見えない問題になり、診断を有意に補正します。 **決断** クラウドインフラに適用されるレート制限の自然な回復で中止された影響。 コンポーネントの非アクティブ化は、初期に可能な原因としてフラグが付けられ、回復と一時的に一致したが、後で事件に関連しないと確認された。 設定修正 — HTTP は、長時間のタイムアウトを有効にし、エッジ保護レイヤーで CDN IP の許可ルールを追加することで、フォローアップ項目として識別されました。 **レッスン内容** CDNとクラウドのインフラ間のネットワーク層の障害が標準のアプリケーション監視に見えないことを強調し、重要な盲点を作成しました。 フォローアップアイテムとして、チームは、プロバイダが推奨する設定修正を実施し、アセットデリバリーレイヤーで保守性を拡大し、このタイプの劣化を積極的に検知する必要を特定しました.

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

1. 2026年7月21日 14:39 UTCidentified

   親愛なる顧客, IDCloud機能の不安定性を調査し、プロセス作成とプロセス詳細フローに影響を与える。 当社のエンジニアリングチームは、できるだけ早く問題を解決するために動員されます。 アップデートを短時間で提供いたします.

2. 2026年7月21日 14:46 UTCidentified

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

3. 2026年7月21日 14:50 UTCmonitoring

   顧客を遅らせて下さい、 当社のエンジニアリングチームは、影響を受けるIDCloudフロー機能の不安定性を解決するために必要な行動を特定し、実施しました。 今回、当社のデータレイヤーの詳細な解析を行い、環境を監視し続けています。 アップデートを短時間でお届けいたします.

4. 2026年7月21日 16:00 UTCresolved

   エグゼクティブサマリーとインパクト 2026年7月21日、約11:17 AM BRTで、IDCloud作成プロセスとプロセスクエリフローで可用性の低下が検出されました。 インパクトウィンドウでは、顧客の一部が、依存するサービスのチェーンを通じて伝播するこれらの操作において、高レイテンシと障害(タイムアウト)を経験しました。 約23分の窓に衝撃が集中しました。 ピーク時、エラーとレイテンシーインジケータは、通常の動作レベル上にあった。 根本原因と決議 これらの機能を原点として支持する読み取りデータベース(レプリカ)の劣化を指摘した調査。 このデータベースは、処理を延期し、読み取りリクエストをバックアップする内部のコンテンツで、負荷とクエリの実行時間を増加させました。 その結果、上記のサービスは、タイムアウトとトリガー保護機構(サーキットブレーカ)を蓄積し、顧客から経験するキャスケーディング効果を生み出し始めた。 コミットメントと次のステップ Unico は、このインシデントを詳細なポストモレテムで処理しており、すでにドラフトされ、ポストインシデントレビュー(PiR)会議が予防措置を集約します。 応答中にすでに上昇したフォローアップの中には、このデータベースレイヤー内のコンテンツの識別を高速化し、関与するデータベース上の観察性が向上するための診断ルーチンとクエリの準備です。 詳細な予防措置は、postmortemで共有されます。 プラットフォームの安定性と信頼性へのコミットメントを再確認し、不安定性の期間中に発生する不便をお詫び申し上げます。 ユニコチーム.

5. 2026年7月28日 12:10 UTCpostmortem

   **概要** 2026年7月21日、11:41と11:43のAM\(Brasília time\)の間、プロセス作成フローは利用できなくなり、メインサービスエラー率は15.75秒で42%とp99レイテンシに達する。 インシデントは、biometryデータベースの読み込みのレプリカの飽和によって引き起こされました。データベースのメモリプールは、最も頻繁にアクセスされたデータセットを提供できなくなり、通常はディスクの読み込みに落ちる高速なクエリを引き起こし、蓄積されたセッションのセルフ補強スパイラルを作成し、レイテンシーを増加させました。 **インパクト** プロセス作成、認証、および支払いのユーザーは、複数のクライアント間でエラーやタイムアウトを受け取ることができます。 プライマリデータベースは、インシデント全体に不当に保たれていました。このエラーは、読み込まれたレプリカに分離されました。 **ルート原因** 根本原因は飽和していた:認証フローで使用されるクエリは、不足しているインデックスによる重要なテーブルの広範なスキャンを実行していた。 通常の条件下では、この動作はデータベースインフラによって許容されるようになりました。 メモリ容量が制限に達し、キャッシュの中で最もアクセスされたデータを保持できなかった場合、各読み取りはディスクからデータを取得し、各クエリの費用は指数関数的に高まりました。 この破産崩壊効果 — 段階的な劣化は、広範な障害への道のりを与える — 応答と内部データベースリソースの満足度を高めるために、セッションが蓄積された待機として自己補強される。 さらに、重要な流れに対するすべての読み取りトラフィックは、単一のレプリカに集中し、分布や代替ルートなし、このタイプの劣化に対する回復力を排除しました。 **決断** 蓄積されたセッションが排出されるにつれて、データベースは自然に回復し、手動介入を必要としません。 データベースチームにエスカレーションされ、サービスの安定化を監視します。 通常の動作が復元されたことを確認した後に、インシデントは閉鎖されました。 **レッスン内容** インシデントは、データベースレイヤー内の構造ギャップを明らかにしました: 重要なクエリと代替ルートなしで単一のレプリカ上のすべての読み取りトラフィックの集中に欠けているインデックス。 フォローアップとして、チームは、欠落したインデックスの作成を優先し、レプリカを横断して読み取りトラフィックを分配し、診断ランブックを構築して、同様の性質の将来の出来事の応答を加速させます.

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

1. 2026年7月20日 12:33 UTCidentified

   顧客を遅らせて下さい、 IDCloudの機能の一部で、GetSelfie、プロセス作成、およびプロセス詳細がWebジャーニー(旧ByUnico)のフローに影響を及ぼす、不安定性を特定しました。 API ジャーニー (ByClient) は影響を受けません。 当社のエンジニアリングチームは、できるだけ早く問題を解決するために動員されます。 アップデートを間近に追っていきます.

2. 2026年7月20日 12:35 UTCidentified

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

3. 2026年7月20日 12:39 UTCmonitoring

   顧客を遅らせて下さい、 当社のエンジニアリングチームは、影響を受けるIDCloudフロー機能の不安定性を解決するために必要な行動を特定し、実施しました。 今回、当社のデータレイヤーの詳細な解析を行い、環境を監視し続けています。 アップデートを短時間でお届けいたします.

4. 2026年7月20日 13:22 UTCresolved

   エグゼクティブサマリーとインパクト プロセスキャプチャと視覚化の流れに影響を及ぼす不安定性、Webジャーニーの認証、0907と0921(BRT)の衝撃を検証しました。 このフローを使用してクライアントの部分に影響が及ぶ、API ジャーニーは影響を受けませんでした。 根本原因と決議 根本原因は、内部データベースコンポーネントの負荷増加を引き起こした生産で適用される設定変更にリンクされます。 これにより、インテグレーションレイヤー内のレイテンシとエラーが増加し、保護メカニズムをトリガーし、Webジャーニーフローを一時的に中断しました。 エンジニアリングチームは、構成変更をロールバックし、問題を軽減し、状況は短時間後に正規化しました。 コミットメントと次のステップ エンジニアリングチームは、変更のロールバック後に環境を監視し続けています。 来日予定日に弊社チームより詳細な郵便物が共有されます。 大変申し訳ございません。 ユニコチーム!

5. 2026年8月4日 14:14 UTCpostmortem

   **Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

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

1. 2026年7月16日 14:02 UTCinvestigating

   顧客を遅らせて下さい、 Unico Peopleポータルの認証システムに不安定性を調査し、IDCloud顧客に影響を与えるメッセージングサービスの問題も評価しています。 当社のエンジニアリングチームは、できるだけ早く問題を解決するために動員されます。 アップデートを短時間で提供いたします.

2. 2026年7月16日 14:08 UTCmonitoring

   顧客を遅らせて下さい、 私たちのチームは、問題を特定し、事件を解決するために行動を取った。 Unico Peopleポータルの認証システムでは、SMSやメール配信のために、IDCloudフローの顧客に影響を及ぼすメッセージングサービスの問題を抱えていました。 当社のエンジニアリングチームは、環境を監視し、適切に機能し続けます.

3. 2026年7月16日 15:28 UTCresolved

   エグゼクティブサマリーとインパクト で 10:51 に 07/16/2026, 問題は、Unico Peopleの入学ポータルとメッセージングで認証サービスで識別されました, ユニコの人々やIDCloudクライアントへのSMSと電子メールリンクの配信に影響しました, だけでなく、ユニコの人々入学ポータル上のB2Cクライアント認証. これらの2つの流れに限られ、製品のコア・クリティカル・ジャーニーには影響しません。 解決まで約30分を経過しました。 根本原因と決議 根本原因はメッセージングクラスターの1つのノードのストレージ圧力として識別され、重要なディスクのしきい値に達し、メッセージ配信と認証を担当するキューの処理を劣化させました。 エンジニアリングチームは、約10:59でクラスターのストレージ容量を増加させました。これにより、キューと監視インジケータは数分で正規化できます。 完全回復が確認されるまで環境を監視し、11:20に事故が閉鎖されました。 コミットメントと次のステップ エンジニアリングチームは、このタイプの劣化に対するアラートのエスカレーションと優先順位付け基準を見直し、アラートは正しく問題を識別するが、責任あるチームが自動エスカレーションフローを改善することができます。 詳細な郵便物を用意し、翌日に共有されます.

4. 2026年8月3日 12:14 UTCpostmortem

   **概要** 2026年7月16日、午前10時12分～午前11時10分の間、メッセージングと認証サービスが約58分劣化しました。 原因は、メッセージキュークラスター内のノードの1つにディスク飽和していました。これにより、設定された制限に達すると、すべてのパブリッシャーを自動的にブロックし、キュー内の最大33千個のメッセージのバックログを引き起こします。 インパクトは、SMSとメールによる認証リンクの配信や、Unico Peopleの入場ポータルのエンドユーザー認証フローに影響しました。 **インパクト** SMSまたはメールによる認証リンクを待っているユーザーは、期間内に受信しなかった。 入学ポータルで認証しようとする人管理プロダクトのエンドユーザもサービスにアクセスできませんでした。 クラスターのディスクを拡張した後に衝撃が含まれている。 **ルート原因** 根本原因は、メッセージ処理フローで識別された:不要なデータを含む監査コンポーネントによって生成された過度に大きなペイロード — メッセージキュークラスターによって受け入れられるサイズ制限を超えました。 すべての試みで決定的に拒否されたので、これらのメッセージは、すべてのリトリーを排気した後にデッドレターキューにルーティングされました。 これらのキューは、有効期限や自動クリーンアップポリシーがなかったため、メッセージが無期限に蓄積し、クラスターのディスクスペースを巧みに消費します。 **決断** クラスターのディスクは、すぐにキューとクラスターのメトリックを正規化し、ノードごとに500 GBに拡張されました。 本サービスは午前11時10時10分に正常に返却されます。 構造的な根本原因 — デッドレターキュー内の無期限の蓄積 — はフォローアップ項目として扱われる。 **レッスン内容** インシデントは、蓄積の根本原因を調査することなく、症状\(disk saturation\)のみに対処するため、問題の再発を保証します。 デッドレターキューのライフサイクルポリシー\(TTL/expiration\)の欠如と、出版前のペイロードサイズの検証の欠如は、修正されるべき2つの中央構造ギャップです。 さらに、問題にフラグが付けられたアラートは優先度が低いため、アラートがトリガーされ、インシデントの正式な開口部の間に約38分遅れが生じました。重要なサービス劣化の許容間隔です.

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

1. 2026年7月13日 12:51 UTCidentified

   親愛なる顧客, IDCloud リクエストの小さな部分でエラーを生成し、本人確認機能の不安定性を特定しました。 当社のエンジニアリングチームは、診断のために既に動員し、可能な限り迅速にサービスを正規化するために根本原因を特定するために働いています。 今回、技術チームはデータレイヤーの詳細な分析を行い、インパクトを軽減します。 今後、より一層のアップデートが届きます.

2. 2026年7月13日 13:06 UTCmonitoring

   親愛なる顧客, 当社のエンジニアリングチームは、IDCloud要求の小さな部分でエラーを生成するアイデンティティ検証機能の不安定性を解決するために行動を特定し、実施しました。 今回は、データレイヤーの詳細な解析を行い、環境を監視し続けます。 今後、より一層のアップデートが届きます.

3. 2026年7月13日 13:47 UTCresolved

   エグゼクティブサマリーとインパクト 2026年7月13日、IDCloudリクエストの最小限の部分でエラーを生成し、複数の認証フローに影響を及ぼす、IDCloudリクエストの不安定性を特定しました。 問題は、9:27 AM BRTの周りの自動可用性アラートを介して検出されました。, 誤差の増加は、すでに約から顕著に増加し、 9:07 AM BRT, ピークの影響に達する 9:49 AM BRT. 根本原因と決議 根本原因は、セッショントークンのシグネチャ検証の失敗を引き起こした内部認証コンポーネントに適用される段階的な変更として識別されました。 根本原因が確認されたら、エンジニアリングチームは変更を反転し、サービス可用性が正常に戻りました。 影響の最も重要なフェーズは、約44分続きます。 コミットメントと次のステップ エンジニアリングは、このタイプのロールアウト中にエラースパイクが発生した場合に自動ロールバック機構を含む、重要な認証コンポーネントに影響を与える段階的なロールアウトに対する変更検証プロセスの改善を評価しています。 次のステップとして内部的に共有することが期待される詳細なpostmortem.

4. 2026年7月20日 22:47 UTCpostmortem

   # Postmortem: 認証フローの安定性 **設立年月日:** 7月13日、2026 ※所要時間:**～44分 ## 概要 2026年7月13日、プラットフォームの認証フローの可用性劣化を特定しました。 インシデントは、セキュリティトークンの有効化を担当する内部コンポーネントのローリング展開中に導入された非互換性によって引き起こされました。 原因は、当社のオペレーションチームによって診断され、更新復元されたシステム安定性を数分でロールバックしました。 ## インパクト 劣化は、約44分持続し、同時にプラットフォーム上で複数の認証フローに影響し、顧客向けサービスで約0.9%の誤差率を生じる。 この期間中、認証しようとすると、一部のエンドユーザーは、不安定性を経験し、一般的なエラーメッセージ\(HTTP 500\)を見ました。 イベントは44分続くが、レイテンシーの増減と不当性が期待される。 ## 根本原因 障害は、セキュリティトークン検証コンポーネントへのアップデートで導入されたソフトウェアの欠陥によって引き起こされ、異なるバージョンを実行しているインスタンス間の不適合性を引き起こしました。 異なるバージョンの同時並列実行を必要とするため、テスト環境ではこの互換性は検出されません。 また、バリデーションが失敗しても内部エンドポイントは HTTP の成功応答を返し、自動導入監視システムが問題を検出し、ロールアウトを自動的に停止することを防ぎました。 ## 決断 原因が特定されたら、オンコールチームが影響を受けたコンポーネントのロールバックを実行し、認証フローの可用性を直ちに復元します。 劣化の数分で自動SLOアラートでインシデントが検出され、エスカレーション機能のフル診断とインシデントの軽減が実現しました。 ## レッスン 転がりの展開でバージョン互換性の検証を改善し、内部エンドポイントの HTTP レスポンスの動作を調整し、自動ロールバックをトリガーし、エラー処理を標準化して、顧客に到達する前にマスクされるのを防ぐことができます。 ## 継続的改善への取り組み このようにして、プラットフォームの信頼性を継続的に改善するためのコミットメントを強化しています。 私たちは、あらゆるインシデントを学習機会として扱い、プロセスを見直し、検出と予防メカニズムを強化し、より堅牢なエンジニアリング慣行に継続的に投資します。 私たちの目標は、すべてのお客様の空き状況と透明性に関するバーの調達を維持することです。 ユニコチーム.

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

1. 2026年7月10日 16:43 UTCinvestigating

   現在、IDCLOUDの機能に不安定性を発揮しています。 当社の技術チームはすでに根本原因を調べています。 情報が増え次第、更新を行います.

2. 2026年7月10日 17:12 UTCidentified

   コア検証とリスク分析 API の一部において、一時的なダウンタイムやレイテンシを引き起こす可能性がある不安定性を特定しました。 欠陥のあるサービス: - アイデンティティと検証: アイデンティティ検証、1:1検証、Serpro類似性リターン - リスクと詐欺:リスクスコア、不正リスク分類 - ドキュメントとライブネス:ドキュメントの再利用とキャプチャ、ライブネス 現在の状態と次のステップ: 当社のエンジニアリングチームは、すでに完全に従事して根本原因を調べています。 行動を正当化し、通常の操作を可能な限り迅速に復元するよう努めています.

3. 2026年7月10日 17:25 UTCmonitoring

   現在のステータスと次のステップ 移行アクションが正常に適用され、システムが安定しています。 今回、エンジニアリングチームは、プラットフォームのパフォーマンスを積極的に監視し、継続的な安定性と正常な動作を保証します。 本件についてご理解いただき、誠にありがとうございます。 お客様のサービスは正常に動作するはずです.

4. 2026年7月10日 17:57 UTCresolved

   エグゼクティブサマリーとインパクト 2026年7月10日、午後1時21分と午後2時16分(Brasília Time)の間、プロセス作成の流れと関連の旅程の可用性の変動を特定し、メインAPIの一部の誤差率で一時的なスパイクをもたらします。 - 影響範囲:この間隔の間に特定の旅程の可用性を独占的に影響するイベント。 この期間中にエラー率が増加したことがなかったお客様は影響を受けませんでした。 - データ整合性:処理された情報の完全性またはセキュリティに妥協はありませんでした。 - 移行:初期の回避策は、数分以内に適用され、エラーの音量をシャットします。 本サービスは、エンジニアリング・モニタリング・チームからの安定性確認後、午後2時16分に完全に正規化されました。 根本原因 インシデントはインフラサービスの不安定性によってトリガーされ、関連する内部コンポーネントの初期化に突然の劣化が続いています。 コミットメントと次のステップ 私達は私達のプラットホームの弾性に深く託されます。 インシデント中に開始された是正および予防措置は、この性質の将来の発生の危険性を緩和するために既に監視されています。 - Postmortem: 詳細な技術的なレポート(Postmortem)は、完全なタイムライン、建築分析、および定義された期限の長期行動計画を含む、すぐに共有されます。 誠に有難うございます。 お客様からの信頼は最優先事項であり、引き続き当社のサービスの卓越性を確保するために継続的に取り組んでまいります。 ユニコチーム

5. 2026年7月14日 14:08 UTCpostmortem

   **概要** 2026年7月10日、午前1時21分から午後2時09分までの間、プロセス作成のエラー率は約11%、午後2時09分まで上昇しました。 インシデントは、インフラ構成管理コンポーネントの不安定性によって引き起こされ、バイオメトリックサービスPodを正しく初期化しないようにしました。 影響は、既存のメモリ消費動作によって増幅されました。\(Podの再起動回数が増えました)、新しいインスタンスの生成をトリガーしたトラフィックスピークにより、構成コンポーネントの不安定性ウィンドウ中に初期化できませんでした。 **インパクト** プロセス作成、認証、生体認証、支払い、内部操作など、複数のフローが同時に影響され、バイオメトリクスエンジンに依存するすべてのサービス間でのエラーが伝播しました。 ピーク時、エラー率は11%に達しました。 利用可能なバイオメトリクスサービスポッドの数は、インシデントの最も重要なウィンドウの間に、生産クラスターのほぼゼロに低下しました。 **ルート原因** 根本的な原因は、バイオメトリクスサービスの起動ロジックの最適化機会に関連していました。インフラ構成管理コンポーネントがブート中に失敗した場合でも、キャッシュされたデータがフォールバックとして使用できる場合でも、アプリケーションは起動を拒否しました。 このロジックは、一時的な通信を永続的な設定エラーと同じ方法で処理し、一番必要な瞬間にフォールバックキャッシュを誤ってレンダリングします。 コンフィギュレーションコンポーネントが不安定になったとき、メモリプレッションやオートスケーリングによる再起動を試みるすべてのポッドは、失敗ループでスタックし、初期化プロセスを完了できません。 **決断** 影響を受けたコンポーネントの1つからトラフィックを分離することにより、初期の衝撃が含まれているため、エラーのスパイクを約9分以内に停止しました。 設定管理コンポーネントの安定化が続くため、Podが正常にバックアップできるようにします。 緊急の修正が準備され、同じ日に展開され、スタートアップをブロックする制限的な検証を削除し、フォールバックキャッシュが同様の状況で透明に使用されます。 **レッスン内容** インシデントは、サービスのレジリエンスメカニズム — フォールバックキャッシュ — アーキテクチャに存在していたが、スタートアップロジックによってニュートラル化され、環境の可用性に対する厳格なデータ検証を優先しました。 重要なサービスに対するスタートアップパスは、インフラコンポーネントが不安定な場合、運用の継続性を確保するために、慎重に劣化するように設計する必要があります。 **安定性と継続的改善へのコミットメント** 今後も、インフラの堅牢性に大きく投資し、サービスが最高水準の効率性、セキュリティ、信頼性で一貫して稼働できるようにします。 ユニコチーム.

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

1. 2026年7月7日 21:22 UTCidentified

   Prezado Cliente, Identificamos uma latência seguida de indisponibilidade na criação de processos de algumas capacidades da Unico. Devido a isso, uma parcela de nossos clientes pode perceber lentidão ou aumento de erros em operações que envolvem o ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Nossa equipe de engenharia já foi acionada e está trabalhando no diagnóstico da causa raiz para normalizar o serviço o quanto antes. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar os impactos. Comprometemo-nos a enviar novas atualizações em breve assim que tivermos novidades. Equipe Unico.

2. 2026年7月7日 21:32 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno das capacidades de ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026年7月7日 22:14 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026年7月13日 21:18 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2026年7月6日 16:29 UTCidentified

   Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com IDScore, que está apresentando lentidão no retorno do Score de autenticação de determinados processos. Clientes que utilizam orquestração com o Trust podem enfrentar também cenários de erros em determinados processos devido a lentidão identificada. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

2. 2026年7月6日 16:51 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno do Score de autenticação. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026年7月6日 17:25 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026年7月13日 21:17 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2026年7月2日 22:04 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br Em breve retornaremos com novas atualizações.

2. 2026年7月2日 22:05 UTCidentified

   We are continuing to work on a fix for this issue.

3. 2026年7月3日 0:04 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimento foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Estamos em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

4. 2026年7月3日 1:14 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

5. 2026年7月13日 20:36 UTCpostmortem

   ### **Postmortem: WhatsApp Support Channel Instability** #### **Summary** On July 2, 2026, an instability affected our WhatsApp customer support channel. During this period, automated messages from our virtual assistant \(bot\) were not being delivered to end-users. Service was fully restored after the identification and rollback of a system change within our technology partner’s environment. #### **Impact** This incident exclusively impacted customers attempting to reach support through our WhatsApp channel. While automated messages managed by the bot failed to deliver, manual messages sent by human agents continued to operate normally. Our alternative support channels, such as email and webchat, remained fully operational and were communicated as active alternatives during the instability. #### **Root Cause** The root cause was an update deployed in the messaging service managed by our technology partner. This update introduced an incompatibility within the partner's own production environment configurations. This supplier-side infrastructure failure disrupted the automated communication flow, preventing the bot from delivering messages. #### **Resolution** Our partner's technical team investigated the issue within their environment and traced the failure back to the recently deployed update. The resolution applied by the vendor consisted of performing an immediate rollback to the previous stable version of their messaging service. Once the partner completed this rollback, message delivery was successfully restored, and our support channel returned to normal operations. #### **Lessons Learned** This incident reinforced the importance of maintaining an agile contingency and communication strategy to quickly redirect our customers to alternative channels \(such as webchat and forms\) during third-party service outages. Additionally, it highlighted the need to continuously align with our key vendors regarding the requirement for more rigorous validation and testing protocols in their own environments before promoting updates that can impact our operations.

1. 2026年6月26日 14:10 UTCresolved

   Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade que causou falhas de acesso na plataforma SafeDoc (através do endereço seu.acesso.io) para um grupo específico de clientes. Durante esse período, alguns usuários enfrentaram dificuldades no fluxo de login, processamento e visualização de imagens e arquivos. A origem do comportamento esteve relacionada a uma atualização programada de manutenção executada na noite de 25/06, que gerou incompatibilidade na parametrização de algumas instâncias do sistema. Nossos times de Engenharia e SRE identificaram o cenário e aplicaram as correções e ajustes de configuração necessários nas instâncias afetadas. O serviço foi restabelecido e está operando normalmente. Lamentamos o ocorrido e seguimos monitorando o comportamento da plataforma para garantir a estabilidade das operações. Em caso de dúvidas, nossa equipe de CX está à disposição. Equipe Unico.

2. 2026年7月3日 18:22 UTCpostmortem

   **Resumo** No dia 26 de junho de 2026, entre 00:17 e 10:40 \(horário de Brasília\), um grupo de clientes enfrentou instabilidade que afetou o acesso a alguns de nossos serviços. A falha se manifestou em erros de login, processamento e acesso a arquivos. Nossa equipe de engenharia identificou a causa e restaurou o serviço para todos os clientes afetados. **Impacto** Durante o incidente, que durou aproximadamente 10 horas e 23 minutos, 24 clientes ficaram impossibilitados de utilizar funcionalidades essenciais de nossos serviços, impactando suas operações. O acesso foi completamente restabelecido às 10:40 do dia 26 de junho de 2026. **Causa Raiz** A causa raiz do incidente foi uma falha durante um processo de atualização programada de sistema, que ocorreu na noite do dia 25 de junho. A atualização de configuração não foi aplicada corretamente em um subconjunto de servidores, fazendo com que o sistema fizesse referência a dependências de software desatualizadas e incompatíveis. Essa falha impediu a comunicação correta com serviços de armazenamento em nuvem e de autenticação, resultando nos erros observados pelos clientes. A ausência de validação automatizada pós-implantação e de alertas centralizados para este tipo de erro de configuração impediu a detecção proativa do problema. **Resolução** Assim que o incidente foi reportado na manhã do dia 26 de junho, nossa equipe de prontidão foi acionada. Foi identificado que a falha estava relacionada a uma implantação incorreta de arquivos de configuração. As equipes de engenharia aplicaram as correções necessárias em todas as instâncias afetadas, restaurando a funcionalidade completa dos serviços. Após a aplicação da correção, foi realizada uma verificação completa para garantir que todos os sistemas estivessem operando normalmente. **Lições Aprendidas** * Automação na validação: Implementações em larga escala exigem verificações automatizadas pós-implantação para garantir que todas as instâncias tenham sido atualizadas corretamente e de forma consistente. * Observabilidade centralizada: É fundamental garantir que os registros de erros de todas as aplicações sejam transmitidos para uma plataforma centralizada, permitindo a detecção rápida de anomalias, mesmo que a falha afete a própria capacidade de comunicação da aplicação. Estamos comprometidos com a confiabilidade de nossos serviços e continuaremos trabalhando para fortalecer nossos sistemas e processos.

1. 2026年6月24日 18:20 UTCidentified

   Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes Mexico que utilizam essa capacidade. A nossa equipe de tecnologia está analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. 2026年6月24日 18:31 UTCmonitoring

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026年6月24日 18:53 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026年7月13日 19:27 UTCpostmortem

   **Summary** On June 24, 2026, between 2:55 PM and 3:26 PM \(Brasília time\), the availability indicator for the process creation flow dropped below 95%, with a total duration of approximately 31 minutes. The incident was caused by an instability in an infrastructure provider used in the risk assessment flow, which began returning errors and latency above expected levels. The impact was concentrated on users from Mexican market clients. **Impact** Users of the process creation and authentication flows that relied on the risk assessment step received timeout errors during the period. The impact was more severe for Mexican market clients but also affected authentication flows for other clients. **Root Cause** The root cause was an instability in the infrastructure provider responsible for the risk assessment step. The provider began operating with latency well above normal and returning errors, causing requests that depended on this step to become blocked and propagate failures to the process creation and authentication flows. Internal services were unable to isolate the impact of the provider's degradation, resulting in widespread unavailability for all users passing through this step. **Resolution** The infrastructure provider stabilized on its own at 3:16 PM. The team identified a timeout configuration need during the incident and opened a correction with explicit values. The incident was closed at 3:50 PM after stability was confirmed. **Lessons Learned** The incident highlighted the need to strengthen isolation mechanisms between internal services and infrastructure providers, so that isolated instabilities do not propagate to end users. As follow-ups, the team identified improvements in the resilience of the affected flows and in the documentation of critical dependencies, aiming to reduce response time and impact in future occurrences of a similar nature.

1. 2026年6月23日 1:24 UTCinvestigating

   Prezado クライアント, Nossa Monitoração proativa pushou um comportamento 不規則な いいえ ID 支払い e no fluxo de オンボーディング 行います ByUnico. アンボラは、カサ・エスタ・エスタ・エスタ・エスタジャ・ソブ・インビスタガセオ、イソ・ポド・セ・マニフェスター・コンポ・レンディド・オ・インターミチェ・ノ・サビソ。 equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar として causas. Em breve retornamos com atualizaçes.

2. 2026年6月23日 1:39 UTCidentified

   Prezado クライアント, Nossa equipe ainda está Investigando a causa raiz do 問題点. Em breve traremos mais atualizaçes. コンペンサンをアオグラデモス.

3. 2026年6月23日 1:53 UTCidentified

   Prezado クライアント, Informamos que nossa equipe identificou a causa da instabilidade e está ativamente trabalhando na aplicação da solução. Seguimos empenhados em restabelecer o serviço mais Rapidamente possível e manteremos você sobre a evolução. Novas atualizaçes serão enviadas em breve.

4. 2026年6月23日 2:18 UTCmonitoring

   Prezado クライアント, Nossa equipe identificou as causas do 問題 e realizou as açes パラ que este 事件 fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nosos canais de atendimento. Atenciosamente, エクイペユニコ!

5. 2026年6月23日 2:41 UTCresolved

   Prezado クライアント, Nossa equipe identificou as causas do 問題 e realizou as açes パラ que este 事件 fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nosos canais de atendimento. Atenciosamente, エクイペユニコ!

6. 2026年7月14日 13:58 UTCpostmortem

   **概要** 2026年6月22日、9:52 PM \(Brasília time\)で、データベースのシーケンシャル識別子制限の排出により、文書保存フローが利用できなくなった。 その瞬間から、すべてのドキュメントのインサート操作が失敗し始め、複数の依存サービスにエラーをキャッシュします。 所要時間約86分 **インパクト** オンボーディングフロー、プロセス作成、認証、支払いなど、複数の重要なサービスが同時に影響されました。 流れによっては3%以下に空室状況が低下します。 クライアントは、文書の保存に依存した操作を試みるときに、障害や遅延の影響を受けました。 **ルート原因** 根本的な原因は、約2.1億個の値をサポートするドキュメントテーブルで使用される32ビットの識別子タイプに関連していました。記録的なボリュームの自然な成長により、この制限が到達し、データベースが新しい識別子を生成できなくなったため、すべてのインサート操作は失敗し始めました。 この限界に近接して追跡する監視がなかったため、排気は突然発生し、事前の警告なしに発生しました。 **決断** チームは、約20分で根本原因を特定しました。 即時の緩和として、シーケンシャル識別子は、同じデータタイプのマイナス範囲を使用するように再構成され、データベースへの構造的な変更を必要としずに約2.1億の値を解放しました。 ソリューションは、生産に適用される前に、下部の環境で検証されました。 修正後すぐに安定化し、完全回復が確認されるまで監視されました。 **レッスン内容** インシデントは、大量の表でシーケンシャル識別子の使用状況の監視を実施する重要性を強調し、排気が計画されたメンテナンスとして処理されることを可能にする早期アラートで; このチェックを含む高書き込みボリュームの表のアウトセットから8バイトの識別子タイプを採用し、コアの持続サービスの重要な依存性をマッピングおよび文書化し、影響をサイズし、将来のインシデントで影響を受けたユーザーとのコミュニケーションを優先する.

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

1. 2026年6月19日 13:08 UTCinvestigating

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 2026年6月19日 18:34 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimentos foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Neste momento, nosso time de engenharia e operações segue em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

3. 2026年6月19日 19:42 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

4. 2026年7月3日 20:36 UTCpostmortem

   **Sumário** No dia 19 de junho de 2026, identificamos uma instabilidade que afetou nosso canal de atendimento via WhatsApp. O incidente, que teve início aproximadamente às 09:00 e foi resolvido às 15:45 \(horário de Brasília\), impediu que nossos agentes acessassem as conversas dos clientes nessa plataforma. A causa raiz foi um problema técnico originado em um de nossos parceiros de tecnologia, que já foi corrigido. **Impacto** Durante o período do incidente, o atendimento aos clientes finais através do canal de WhatsApp foi impactado. Como alternativa, os clientes foram orientados a utilizar nossos outros canais de contato, como formulário, e-mail e webchat. As operações foram normalizadas no mesmo dia. **Causa Raiz** A investigação, conduzida em conjunto com nosso parceiro tecnológico responsável pela plataforma de gestão de conversas, revelou que a causa do incidente foi uma alteração de certificados de segurança em um sistema terceiro com o qual a plataforma se integra. Essa alteração invalidou o mecanismo de autenticação utilizado pelo serviço, impedindo a comunicação entre a plataforma de atendimento e o canal do WhatsApp. A detecção do problema foi reativa, pois a falha de autenticação não gerava alertas proativos e o ambiente de testes não utiliza os mesmos certificados do ambiente de produção, o que impediu a reprodução do erro em testes preliminares. **Resolução** Após a identificação do problema, a equipe de engenharia do nosso parceiro tecnológico atualizou os certificados de autenticação em seus sistemas para restabelecer a compatibilidade com a plataforma terceira. A correção foi aplicada e validada, normalizando o acesso dos nossos agentes às conversas e restaurando completamente o serviço de atendimento via WhatsApp às 15:45. **Lições Aprendidas** * É crucial manter uma comunicação ativa e monitorar os canais de parceiros tecnológicos para se antecipar a mudanças que possam impactar os serviços integrados. * Falhas de autenticação com serviços externos são um ponto crítico e devem possuir mecanismos de alerta específicos para permitir uma detecção e resposta mais rápidas, reduzindo o tempo de indisponibilidade. Estamos empenhados em garantir a estabilidade e a qualidade de nossos canais de atendimento e continuaremos a trabalhar em estreita colaboração com nossos parceiros para fortalecer a resiliência de nossos serviços.

1. 2026年6月12日 15:29 UTCidentified

   Prezado Cliente, Estamos acompanhando uma instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações.

2. 2026年6月12日 17:03 UTCidentified

   Prezado Cliente, Seguimos acompanhando a instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações

3. 2026年6月12日 18:17 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

4. 2026年6月12日 18:31 UTCresolved

   Prezado Cliente, Incidente resolvido. As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

1. 2026年6月12日 14:58 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via e-mail ou nos contatarem pelo nosso webchat como alternativa de contato sincrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 2026年6月12日 17:31 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas pelo nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido Atenciosamente, Equipe Unico

3. 2026年6月12日 18:00 UTCresolved

   Prezado Cliente, Incidente resolvido. as ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico