Knowbe4 の障害履歴

1. 2026年9月4日 10:53 UTCinvestigating

   We have received reports of an issue with delivery of Email verification MFA for Workspace. We are investigating this issue and will update this page when we have more information.

2. 2026年9月4日 14:24 UTCmonitoring

   We have received reports that the issue with delivery of Email verification MFA for Workspace has been mitigated by Microsoft, and we are monitoring the results.

3. 2026年9月7日 8:25 UTCresolved

   This incident has been resolved.

1. 2026年8月26日 16:19 UTCinvestigating

   We have identified an issue where users may experience delays in messages being processed, and our engineering team is looking into a fix.

2. 2026年8月26日 16:46 UTCmonitoring

   Our engineering team has implemented a fix for the issue that causing message processing delays in PhishER, and we are monitoring the results.

3. 2026年8月26日 19:51 UTCresolved

   Our engineering team has implemented a fix for the issue that causing message processing delays in PhishER.

1. 2026年8月21日 8:52 UTCinvestigating

   We have received reports that the Gmail Phish Alert Button shows the error "[reportPhishAttempt()] An internal error has occurred. Please try again." when reporting phish. We are investigating this issue and will update this page when we have more information.

2. 2026年8月21日 12:03 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026年8月21日 13:08 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026年8月21日 14:57 UTCresolved

   This incident has been resolved.

5. 2026年8月26日 15:55 UTCpostmortem

   On Friday, August 21, 2026, from approximately 05:20 to 12:55 \(UTC\), some customers experienced intermittent failures when using the Gmail Phish Alert Button add-in to report suspicious emails, receiving the "An internal error has occurred" message instead of a successful report confirmation. The issue affected customers across all regions, with the highest error volumes concentrated in the EU-West and US-East service regions. This issue was caused by a disruption in a caching service on Google's Apps Script platform, which the add-in relies on to store per-user session configuration. The service began intermittently returning empty results on read while still accepting new writes, causing affected report submissions to fail. KnowBe4 engaged Google directly and filed a formal bug report between approximately 12:19 and 12:39 \(UTC\). Error volume declined sharply shortly after as the vendor-side condition cleared, and the Gmail Phish Alert Button returned to normal performance by approximately 12:55 \(UTC\). To prevent this type of issue in the future, we are continuing to work with Google to track the resolution of the underlying caching defect. No data loss occurred as a result of this issue.

1. 2026年8月18日 14:29 UTCinvestigating

   We are investigating an issue causing a Non-Delivery Report (NDR) to be returned when a message is reported via the Phish Alert Button and "Send Us a Copy" is enabled in Account Settings

2. 2026年8月18日 15:26 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026年8月18日 20:14 UTCresolved

   This incident has been resolved.

1. 2026年8月5日 19:29 UTCinvestigating

   We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.

2. 2026年8月5日 21:24 UTCmonitoring

   Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.

3. 2026年8月6日 21:56 UTCresolved

   Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.

1. 2026年8月4日 19:19 UTCidentified

   We have identified an issue preventing account settings from loading in the SAT console.

2. 2026年8月4日 19:51 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026年8月5日 12:17 UTCresolved

   This incident has been resolved.

1. 2026年7月28日 20:00 UTCinvestigating

   PhishRIP が予期せぬメールに関連した問題を調査しています

2. 2026年7月28日 20:35 UTCmonitoring

   この問題では修正が実装され、PishRIP のクエリは、予期しないと宣言されたメッセージには適用されません。 影響を受けている可能性のある質問はまだ調査中です

3. 2026年7月29日 18:58 UTCresolved

   この事件は解決しました.

4. 2026年7月30日 16:38 UTCpostmortem

   ##**概要** 2026年7月28日、PishRIPサービスのアップデートにより、PishRIP検索クエリがより広範囲にマッチするようになりました。 設定された送信者基準を満たしていないベニグメールは、一部の顧客のアカウントで検疫されました。 自動監視とカスタマーサポートのチケットは、問題の早期に直面しました。 エンジニアリングは、事件を宣言する約25分以内に変化を反転し、未知の検疫を停止しました。 エンジニアリングは、手動で顧客の受信トレイに不適切な保証されたメールを復元しました。 ##**ルート原因** 2026年7月28日、PishRIPの背後にあるクエリサービスにメンテナンス更新を導入しました。 このアップデートは、システムがアドレスのドメイン部分だけを検索できるように、無効な送信者のアドレスの処理を改善するために設計されました。 しかし、既存のバリデーションロジックは、送信元フィールドの「@」記号を必要とする正規表現を使用しました。 [example.com](http://example.com) のような bare ドメインをユーザ名や "@" 記号なしで使用した場合、regex はドメインを無効にフラグ付けしました。 既存のバリデーションとドメイン調査の更新との間のこの競合により、システムが送信者基準を完全に低下させました。 クエリは、意図した送信機の外でよくメールを一致し、検疫する、残りのパラメータのみを使用して受信トレイに対して実行されます。 ##**タイムライン** UTCには常にあります。 |**時間** | **イベント** | | お問い合わせ | | 19:36 | 自動化されたモニタリングは、異常なクエリ実行パターンを検出し、すぐに調査を開始したエンジニアに警告しました。 お問い合わせ | 19:51 | 高品位生産事件にエスカレーションされ、対応チームを組み立てました。 お問い合わせ | 19:52 | 弊社のサポートチームは、予期せぬ検疫を報告し、監視アラートを腐食させる最初の顧客チケットをエスカレーションしました | | 19:54 | 根本原因は、最近のクエリAPI展開に追跡され、エンジニアリングは変更を再開しました。 | | 20:00 | 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 特定非営利活動法人 | 20:16 | 展開が全面改装されました | | 20:35 | 生産点検では、被験者やドメインの問い合わせが意図した目標だけに再び一致していたことを確認し、さらに、誤ってメッセージが付与されていないことを確認しました。 ステータスページをアップデートしました。 お問い合わせ | 20:39 | エンジニアリングは、誤って保証されたメールの復元を開始しました | | 03:49 \(翌日\) | カスタマーサポートチームでログアウトしたすべての顧客クエリセットの復元が完了しました | ##**緩和と是正** **コードの逆転。** 私たちは、コードを反転に対して、アクティブな PhishRIP 操作のミッドランをハッキングしました。 背景タスクを隠すと、すべてのテナントに対して正当なセキュリティワークフローが中断されるため、逆転はより良いオプションでした。 エスカレーションの約40分以内に、コードが再変換され、生産で検証されました。 **メールの復元.** 顧客環境に本物的に悪意のあるメールを解放することを避けるため、手動で一括して復元しました。 エンジニアリングは、社内の管理者ツールを使用してメールをバッチで復元し、各アカウントID、クエリID、および顧客の承認を最初に確認するためにサポートと協力しました。 報告されたアカウントはすべて一晩に復元されました。 ##**予防措置** * **回帰カバレッジ**: ドメインのみ、標準外、およびベア文字列の送信者クエリ用のユニットと統合テストを追加して、デプロイ前にこれらの入力ケースをキャッチします。 * **問い合わせガードレール**: コアフィルタリングパラメータが評価中にドロップされていれば、実行中のクエリをブロックするクエリエンジンにチェックを追加します。 ## **結論** 単一のバリデーションルールがこれを引き起こしました。すべての送信者フィールドに `@` が含まれていると仮定した正規表現です。 クエリが bare ドメインを使用していたとき、その仮定は、送信者フィルターをドロップし、意図したよりもはるかに多くのメールにマッチしたクエリをドロップします。 修正は、発見した直進し、逆転は事件を宣言する約25分以内に損傷を停止しました。 検疫メールの復元は、より困難なプロセスでした。悪意のあるメールが受信トレイに戻ってくることを危険にさらすことなく、大量のメールを復元できませんでした。 当社のチームは、夜間にサポートをすることで、慎重に作業アカウントを進めることを選択しました。 2つの予防策は、この先をキャッチしました:ドメインのみの送信者クエリをカバーするテストと、送信者のフィルタが除去されたときにクエリを実行することを拒否するガードレール。 どちらも予定されています。 即時の問題は解決され、すべての報告されたアカウントは復元されています。 ##**用語集** * * *PhishRIP:** 管理者が組織内のすべてのユーザーの受信トレイにメールをフィッシングしたり、検疫したりできるPishER機能。 ***Regex \(正規表現\):** ソフトウェアで使用されているパターンは、メールアドレスが正しくフォーマットされていることを確認し、テキストを検索し、入力を検証します。 * ** コードの逆転:** ソフトウェアの更新をバックアップして、以前の安定したバージョンに戻します.

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

1. 2026年7月17日 13:18 UTCinvestigating

   弊社では、ストアの「保護ライセンス」の購入ができないユーザーを調査しています。knowbe4.com 詳細については、このページを更新いたします.

2. 2026年7月17日 18:55 UTCmonitoring

   修正を実装し、結果を監視して、さらなる問題が起きないようにします.

3. 2026年7月20日 18:24 UTCinvestigating

   お客様がストアでProtecライセンスを購入できないという報告をいただきました。knowbe4.com. この問題を調査し、より多くの情報を持っているときにこのページを更新します.

4. 2026年7月29日 18:40 UTCmonitoring

   オンラインストアの修正を実装し、さらなる問題が起こらないよう結果を監視しています.

5. 2026年8月17日 21:02 UTCmonitoring

   We are continuing to monitor the implemented fix for the online store, to ensure that no further issues occur.

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

1. 2026年7月16日 19:48 UTCinvestigating

   ユーザーが Defend にログインしたときにリダイレクトを受け取ることができる問題を特定し、当社のエンジニアリングチームは修正を検討しています.

2. 2026年7月16日 20:09 UTCidentified

   修正が確認され、結果がロールアウトするように監視されます.

3. 2026年7月16日 21:20 UTCresolved

   この事件は解決しました.

4. 2026年8月20日 21:32 UTCpostmortem

   On Thursday, July 16, 2026, from approximately 19:57 to 21:12 \(UTC\), some customers experienced difficulty logging in to the Defend console, seeing a **Find Out More** screen instead of console access. This issue was caused by a synchronization issue between Salesforce and our internal licensing systems, which incorrectly set some customer license counts to zero. As a result, affected customers were unable to log in. To resolve this issue, our team applied a temporary license override to restore access for affected customers while correcting the underlying licensing records in Salesforce. Once corrected, the systems automatically synchronized the accurate values, and the Defend console access returned to normal performance by approximately 21:12 \(UTC\). To prevent this type of issue in the future, we are implementing improvements to the Salesforce synchronization process to ensure accurate license counts. No data loss occurred as a result of this issue.

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

1. 2026年7月15日 16:51 UTCinvestigating

   弊社では、ストアの「保護ライセンス」の購入ができないユーザーを調査しています。knowbe4.com 詳細については、このページを更新いたします.

2. 2026年7月15日 16:54 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年7月16日 1:23 UTCmonitoring

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

4. 2026年7月16日 14:04 UTCresolved

   この事件は解決しました.

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

1. 2026年7月22日 21:01 UTCresolved

   上流機能のフラグサービスの問題は、コラボレーションインフェレンスでモデルのルーティングを劣化させ、PhishML評価を0/0/0のデフォルトエラーを返します。 サードパーティは、修正をデプロイし、静的なフォールバックルーティングを追加する生産にコード更新がデプロイされました。 すべてのサービスは回復し、正常に動作しています.

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

1. 2026年7月1日 14:40 UTCinvestigating

   We have received reports that users are experiencing issues when logging into the US instance. We are investigating this issue and will update this page when we have more information.

2. 2026年7月1日 16:02 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026年7月1日 18:01 UTCresolved

   This incident has been resolved.

4. 2026年7月8日 18:52 UTCpostmortem

   ## **Executive Summary** On July 1, 2026, the KnowBe4 Security Awareness Training \(KSAT\) platform experienced a period of degraded performance resulting in intermittent login errors and high latency for users on our United States \(US\) instance. The issue was initiated following a routine platform deployment that introduced an unoptimized database query. This query placed an excessive operational load on our primary database reader cluster, causing database sessions to saturate and subsequent login requests to queue up. Engineering teams promptly identified the degradation, reverted the deployment, and systematically cleared the backlogged database sessions to restore optimal performance. The issue did not affect data integrity or security, and service was fully stabilized. ## **Technical Root Cause** The root cause was determined to be a newly introduced query within a standard application update. Upon deployment, this specific query pattern bypassed optimal indexing strategies, resulting in full table scans and highly extended execution times on the database reader infrastructure. As a high volume of authentication and application requests arrived concurrently, the database reader quickly exhausted its available connection pool due to these long-running, unmitigated database sessions. This resource starvation immediately manifested as severe application latency and intermittent timeouts during the user authentication process. ## **Timeline of Events** The incident began in the mid-morning hours and progressed through identification, remediation, and verification stages over a period of approximately 152 minutes. An internal high-severity incident response group was established immediately following automated monitoring alerts indicating that health checks targeting our application programming interface \(API\) routing layer were failing from regional cloud monitoring nodes. This behavior was confirmed by concurrent engineering analysis of user HTTP Archive files, which demonstrated severe latency spikes specifically isolated to the authentication endpoints. Within three minutes of establishing the response team, cross-referencing recent system changes pointed to a recent application deployment as the primary catalyst. Engineers immediately initiated the rollback process, drafting and approving a revert modification to extract the problematic code from the deployment pipeline. The deployment of the reverted codebase to the US production cluster commenced shortly thereafter. While the deployment processed over the subsequent twenty-five minutes, technical personnel prepared direct database interventions to clear the residual system strain. Once the stable code version was completely active across the fleet, engineers began systematically terminating the lingering, long-running database sessions that had been spawned by the unoptimized query. To ensure a pristine state, the database reader infrastructure was cycled twice. Following these administrative infrastructure restarts, operational telemetry showed the database reader load dropping significantly to a healthy baseline of approximately thirty-six percent. System performance normalized, and administrative logging verified that authentication requests were processing within standard latency thresholds. After monitoring the environment to confirm sustained stability, engineers officially marked the incident as mitigated, later shifting the status to fully resolved following an extended window of zero performance spikes and complete passes on all automated sanity test suites. ## **Mitigation** To alleviate the immediate infrastructure distress and restore user access, the engineering team executed a multi-phased mitigation strategy: * **Codebase Rollback:** The changes introduced in the recent deployment were immediately isolated, reverted, and redeployed to production to prevent any further generation of the unoptimized query. * **Database Session Termination:** Internal engineering tools were utilized to explicitly terminate active, long-running database queries that were blocking the connection pools. * **Infrastructure Cycling:** The database reader instances were restarted twice in succession to flush out stale memory allocations and guarantee that all orphaned database sessions were permanently cleared. ## **Preventative Measures** To prevent a recurrence of this specific issue and mitigate the impact of similar query-based database bottlenecks in the future, KnowBe4 is implementing the following actions: * **Enhanced Query Linting and Analysis:** Integrate automated query execution plan analysis into our continuous integration and continuous deployment pipelines to flag unindexed or high-cost queries before they reach production environments. * **Database Connection Pooling Guardrails:** Adjust database timeouts and implement aggressive circuit-breaker thresholds for user authentication paths to prevent single, long-running query patterns from exhausting the entire connection pool. * **Load Shedding Policies:** Implement strict application-level timeouts on read-heavy database calls to ensure they fail gracefully rather than degrading the overall availability of the core login workflows. ## **Conclusion** We sincerely apologize for the inconvenience and friction this performance degradation caused our customers and partners. KnowBe4 is dedicated to maintaining high availability and reliability across our product suites. By refining our pre-deployment automated query validation and bolstering our database connection resiliency, we are actively working to ensure the continuous, seamless operation of the KSAT platform. ## **Glossary of Technical Terms** * **API \(Application Programming Interface\):** A set of protocols that allows different software applications to communicate with one another. In this context, it routes authentication requests from the user interface to the backend servers. * **Database Reader:** A dedicated database instance or cluster responsible for handling read-only queries \(such as fetching user profiles or validating login configurations\), separating this traffic from write operations to optimize performance. * **HAR \(HTTP Archive\) File:** A JSON-formatted log file that records a web browser's interaction with a website, used by engineers to diagnose performance and network latency issues. * **Latency:** The time delay or duration it takes for a data packet or request to travel from its source to its destination and return a response. * **Sanity Suite:** A collection of automated tests executed against a deployment environment to quickly verify that the core functionality of an application is working correctly.

1. 2026年6月30日 16:14 UTCinvestigating

   We have received reports that emails sent to Defend are experiencing delays being delivered to inboxes using SMTP. We are investigating this issue and will update this page when we have more information.

2. 2026年6月30日 19:46 UTCresolved

   This incident has been resolved.

3. 2026年7月3日 15:23 UTCpostmortem

   #### Summary On June 30, 2026, customers using the Defend US service experienced delays in email processing. The incident began at approximately 14:00 UTC and was fully resolved by 19:45 UTC. ‌ #### What Happened A scheduled maintenance operation began in the early morning of June 30. As this operation progressed, it placed an unexpectedly high load on our infrastructure, which caused email processing to slow down across our US service. ‌ Our team identified the issue and declared an incident at 16:00 UTC. Steps were taken to reduce the load and restore normal processing speeds, including pausing non-essential background activity and engaging our infrastructure provider for additional support. ‌ By 17:45 UTC, email delivery delays had been fully resolved. Email analysis continued to recover and was back to normal by 19:45 UTC. ‌ #### Customer Impact Email delivery \(SMTP customers\): Emails were delayed in transit by up to 30 minutes between approximately 14:00 UTC and 17:45 UTC. All emails were delivered; no messages were lost. ‌ Email analysis \(Microsoft 365 / Graph API customers\): Email analysis was delayed by an average of 30 minutes before emails were analysed, between approximately 14:00 UTC and 19:45 UTC. Email delivery to end users was not affected. ‌ #### What We Are Doing We have rescheduled the maintenance operation that triggered this incident to run during an overnight, low-traffic window, giving it sufficient time to complete without affecting the live service. ‌ We are also investing in infrastructure improvements to better isolate maintenance operations from customer-facing workloads, so that future maintenance cannot affect email processing in this way.

1. 2026年6月30日 14:18 UTCinvestigating

   PhishML の評価が「PML:BYPASSED」タグが適用される問題を特定しました.

2. 2026年6月30日 15:42 UTCmonitoring

   PhishER の修正を実装し、さらなる問題が起きないように結果を監視しています。 影響を受けたメッセージは、すべてのルールや行動を通して再生することができます。 この場合、このインシデント中にアクションが正常に実行された場合に、重複した応答が送信される可能性がありますのでご注意ください。 ご不明な点がございましたら、サポートチームに直接お問い合わせください。https://support.knowbe4.com/hc/en-us/requests/new 次のナレッジベースの記事には、メッセージを再生する方法に関する手順が含まれています: https://support.knowbe4.com/hc/en-us/articles/13169303385619-PhishER-Inbox-Guide#h 01HCNEBF8CJQ98GE9PGM7HGDZ0

3. 2026年6月30日 19:11 UTCresolved

   この事件は解決しました.

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

   2026年6月30日(火)頃から13時40分から19時15分まで、PishERのPishMLのスコアリングによる誤った結果が出ました。 影響を受けたメールは、正当な PhishML の分類ではなく PML:BYPASSED のタグを受け取り、影響を受けたメッセージから自信のスコアが欠落しました。 PhishML 結果に依存するルールとアクションも活性化しませんでした。 この問題は、約2週間前に導入されたコードリファクターによって引き起こされました。 このリファクタは、PishMLスコアリングに必要な重要なドライバを省略した故障したアップデートを導入しました。 しかし、問題は別のアップデートが新しいPishMLモデルの展開をトリガーするまで、休眠状態のままにし、その問題が発生した。 この問題を解決するために、チームは最後の安定的な展開に戻り、メール評価の結果のバックログを処理する能力を追加しました。 Phisher の PhishML のスコアリングは 19:15 によって正常な性能に返しました\(UTC\)。 今後、このタイプの問題を防ぐため、導入前の新しいモデルの煙テストの新しいエンドポイントを導入することで、健康チェックを改善しました.

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

1. 2026年6月24日 15:48 UTCinvestigating

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC, and our engineering team is looking into a fix.

2. 2026年6月24日 22:06 UTCmonitoring

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC. A fix has been implemented, and we will continue to monitor this issue.

3. 2026年6月25日 13:10 UTCresolved

   We have identified an issue where users may receive a 500 error upon logging into KCM GRC. A fix has been implemented, and users should be able to login without error.

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

   From Tuesday, June 23, 2026, at approximately 10:03 \(UTC\) to Thursday, June 25, 2026, at approximately 11:54 \(UTC\), some US and EU customers experienced intermittent 502 errors when logging in to KCM GRC. This issue was caused by network traffic attempting to connect to invalid multilevel subdomains, which overwhelmed the cache serving KCM GRC and resulted in login errors. Our team initially updated the configuration of our content delivery network, which temporarily resolved the errors, but they returned later that day. After further investigation, we identified the caching issue as the root cause and deployed an infrastructure-level fix to prevent multi-level subdomain traffic from affecting the cache. KCM GRC returned to normal performance by 11:54 \(UTC\) on June 25, 2026. To prevent this type of issue in the future, we are evaluating additional protections to guard against similar traffic that could affect the cache. No data loss occurred as a result of this issue.

1. 2026年6月18日 21:14 UTCinvestigating

   We have received reports of the Phishing test reports tab currently being unavailable. We are investigating this issue and will update this page when we have more information.

2. 2026年6月18日 21:16 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026年6月18日 22:42 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026年6月19日 14:01 UTCresolved

   This incident has been resolved.

5. 2026年7月7日 19:45 UTCpostmortem

   From Tuesday, June 16, 2026, at approximately 17:34 \(UTC\), to Thursday, June 18, 2026, at approximately 22:41 \(UTC\), some customers experienced intermittent unavailability of the **Phishing Security Test Reports** page in the KnowBe4 console. This issue was caused by a code change that introduced a conflict between two methods for processing phishing campaign data. As a result, phishing campaigns still using legacy phishing categories were unable to load the **Phishing Security Test Reports** page. To resolve this issue, we updated the code to process campaigns correctly under both classification systems, and the **Phishing Security Test Reports** page returned to normal performance by June 18, 2026, at 22:41 \(UTC\). No data loss occurred as a result of this issue.

1. 2026年6月18日 15:13 UTCinvestigating

   We have received reports that the Human Risk Managment widget is showing no results in the KnowBe4 Security Center. We are investigating this issue and will update this page when we have more information.

2. 2026年6月18日 15:43 UTCmonitoring

   We’ve implemented a fix for the Human Risk Management widget and we’re monitoring the results to make sure no further issues occur.

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

   This incident has been resolved.

4. 2026年9月8日 15:44 UTCpostmortem

   From Wednesday, June 17, 2026, at approximately 19:00 \(UTC\), to Thursday, June 18, 2026, at approximately 18:20 \(UTC\), some customers were unable to view results in the KnowBe4 Security Center’s Human Risk Management widget. ‌ This issue was caused by a recent infrastructure migration that left an internal service connection pointing to an outdated endpoint. Though the underlying data processing was unaffected, the Human Risk Management widget could not retrieve data or display results. To resolve this issue, our team updated and reapplied the connection configuration, and the KnowBe4 Security Center returned to normal performance by approximately 18:20 \(UTC\) on June 18, 2026. To prevent this type of issue in the future, we are improving our migration process to ensure that all endpoints are valid after a migration. We are also strengthening known-good rollback procedures in cases where a migration cannot be completed as planned. No data loss occurred as a result of this issue.

1. 2026年6月16日 22:23 UTCinvestigating

   We've identified an issue that has resulted in inconsistent reporting, and our engineering team is looking into a fix.

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

   A fix has been implemented and we are monitoring the results.

3. 2026年6月17日 20:19 UTCresolved

   This incident has been resolved.

4. 2026年8月21日 18:00 UTCpostmortem

   From Tuesday, June 16, 2026, at approximately 22:23 \(UTC\), to Wednesday, June 17, 2026, at approximately 20:19 \(UTC\), some customers experienced inaccurate user counts in KSAT reporting. Downstream features that rely on this data were also affected, including AIDA Orchestration, Risk Score, and ModStore recommendations. This issue was caused by an incomplete rebuild of the users' data table. A data storage policy removed historical data earlier than intended, so when a full table rebuild ran, some older data was unavailable, causing user counts to drop. To resolve this issue, our team performed a full data migration sync on the users' table and retriggered the dependent data pipelines to update downstream systems. We then tested and confirmed that user counts were returning correct results, and the KSAT console returned to normal performance by June 17, 2026, at 20:19 \(UTC\). To prevent this type of issue in the future, we are correcting the underlying data storage policy to ensure complete historical data is retained for the full rebuild process. No data loss occurred as a result of this issue.

1. 2026年6月15日 16:56 UTCresolved

   This incident has been resolved.

2. 2026年8月20日 19:41 UTCpostmortem

   On Monday, June 15, 2026, from approximately 15:30 to 16:34 \(UTC\), some customers experienced processing delays with phishing and training campaigns in the KnowBe4 console. This issue was caused by an update that introduced an incompatible software version. This software prevented our background processing service from completing queued tasks. As a result, training enrollments, notification sending, and SmartGgroup enrollments were delayed. To resolve this issue, our team deployed a fix that reverted the affected dependency and restored normal job processing. Once the fix was deployed, the affected queues cleared, and the KnowBe4 console returned to normal performance by 16:34 \(UTC\). To prevent this issue in the future, we have implemented additional testing layers for similar deployments. No data loss occurred as a result of this issue.

1. 2026年6月3日 15:07 UTCinvestigating

   ユーザープロファイルにナビゲートすると500エラーが発生しました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.

2. 2026年6月3日 16:16 UTCmonitoring

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

3. 2026年6月3日 18:14 UTCresolved

   この事件は解決しました.

4. 2026年7月15日 15:23 UTCpostmortem

   6月3日(水)、2026日(水)は、約14:49から16:09\(UTC\)まで、KSATコンソールで**ユーザー詳細**ページにアクセスしたときに、顧客によるエラーが発生しました。 この問題は、欠落したフィールドを導入したアップデートで、**User Details**ページの読み込みを防止しました。 この問題を解決するために、当社のチームは、行方不明のフィールドを復元するために再びコンソールを更新し、KSATコンソールは、約16:09\(UTC\)で通常のパフォーマンスに戻りました。 今後同様の問題を防ぐため、自動テストを追加しました。 この問題の結果としてデータ損失が発生しません.

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