予防 - 新しいドメイン登録アドバイスを欠く
Issues軽微なインシデント
影響を受けたコンポーネント
ConsoleConsole
- identified
ドメイン登録によるアドバイスができない原因を特定し、修正の実行に取り組んでいます。 ステータスページにて、新しい情報や更新情報を掲載しています.
- monitoring
修正を実装し、結果を監視しています.
- resolved
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
80 Knowbe4 incidents · 2025年9月 — official updates, affected components, duration and resolution details.
ドメイン登録によるアドバイスができない原因を特定し、修正の実行に取り組んでいます。 ステータスページにて、新しい情報や更新情報を掲載しています.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、コンソールのログインに影響を及ぼす問題について調査しています。 更新情報はこちらにてご案内いたします.
修正を実装し、結果を監視しています.
この事件は解決しました.
##**概要** 2026年10月13日には、約14:19から15:05 \(UTC\)まで、すべての地域での顧客は、KnowBe4 Security Awareness Training \(SAT\)コンソール、KnowBe4 Learner Experience、およびKnowBe4 SATによるPishERコンソールにログインできませんでした。 SAML とパスワードのログインはエラーを返し、KnowBe4 SAT コンソールは、KnowBe4 プラットフォームには表示されません。 ユーザーの同期と訓練メールを含むバックグラウンドプロセスも、この間に失敗しました。 事件は、コードの別の変更と競合した生産リリースによって引き起こされました。 リリースを反転し、14:59と15:05の間で地域を横断してログインを再開しました。 この問題の結果としてデータ損失が発生しません。 ##**ルート原因** 起動設定値を削除し、アプリケーション起動時間を短縮します。 元の変更がテストされた後、別のコンポーネントがコードに追加され、その変更された値のアカウントはなかった。 その結果、ユーザレコードを保存しようとすると、サインインの試みを記録する更新を含むエラーが発生した。 ##**顧客への影響** SAMLやパスワードでKSATコンソールにログオンできなかったすべての地域の顧客。 学習者エクスペリエンスにアクセスできず、KnowBe4 SAT コンソールから PhishER コンソールにアクセスできませんでした。 今回失敗した新規ユーザー作成、ユーザ同期、およびトレーニングメールが、デプロイ後に自動的に取得されました。 ##**緩和と是正** デプロイメントは、他のコンポーネントがまだ必要としている設定値を削除しました。 リリースを逆転させることで緩和され、直接チェックや自動テストで全地域の回復を確認しました。 また、ソースコードの元の変更を反転し、互換性の修正を含む修正バージョンを用意しましたので、元の改善は安全に再導入することができます。 ##**予防措置** デプロイのコード検証やテストを追加しています.
公式のインシデント更新を自動翻訳しています。
弊社では、Eメール送信時に「既知のEメールセキュリティアドイン」のエラーが表示されていると報告しています。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
Web Add-in 送信エラーの修正を実装し、結果を監視して、さらなる問題が起きないようにします.
この事件は解決しました.
2026年10月12日(月)から、約14:25(UTC\)、火曜日、10月13日(火)、約15:07(UTC\)、EUのEUインスタンスにおける一部の顧客は、Microsoft Outlookからのメール送信を防止し、保護しました。 感染したメッセージは送信されず、KnowBe4メールセキュリティアドオンは、次のエラーが表示されます。 「このメッセージが送信されるのを防ぐアドインのKnowBe4メールセキュリティ」 この問題は、同じバージョンの2つのわずかに異なるコピーを生成したリリース用のバージョンが準備された方法のエラーによって引き起こされました。 Outlook がアドインをロードするとき, それは一致しなければならないファイルのセットをダウンロード. EU インスタンスでは、Outlook は両方のコピーからファイルを受け取ることがあります。そのため、add-in は読み込みを終了できなかったため、メッセージは送信されません。 一部のデバイスは故障したダウンロードを保存しているため、修正が適用されるまで、それらのデバイスにエラーが続行されます。 この問題を解決するために、当社のチームは、すべての顧客が一致するセットを受け取るように、EUのアドオンファイルを修正しました。 その後、保存されたエラーをクリアしたすべての地域にアドオンの更新バージョンをリリースしました。 2026年10月13日、KnowBe4メールセキュリティアドオンは、通常のパフォーマンスに戻りました。 今後、このタイプの問題を防ぐため、各バージョンが常に同じファイルセットを生成し、すべての顧客は同じバージョンを同時に受け取るように、追加版の用意とリリース方法を変更しています。 また、Add-inファイルのダウンロードがデバイスに保存されていないため、Add-inを変更しています。 最後に、それらをより早く検出するために、追加の読み込みエラーのアラートを追加します。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
現在、米国サーバーの防護・保護のために劣化した性能に関する問題を調査しています.
米国では、パフォーマンスを劣化させてしまった米国防護・防護の問題を識別しました。 修正を実施し、引き続きこの問題を監視します.
この事件は解決しました.
##**概要** 2026年9月28日(月)から、約16時00分(UTC\)、9月30日(水)、約12時35分(UTC\)、一部の顧客は、米国防護インスタンスにアクセスするメールフローと断続的な問題の遅延を経験しました。 9月28日、モニタリングでは、各時間トップのスパイクで、ネットワークトラフィックが重いことがわかりました。 一部の顧客は、防護コンソールの米国インスタンスにアクセスする断続的な問題を経験し始めました。 メール処理が開始されたタイミングに依存し、その結果としてメッセージがキューに入れられた内部ルックアップ。 カスタマーサポートチームに問題が報告され、ステータスページ通知を投稿しました。 米国のトラフィックが減少すると、後日、パフォーマンスが回復しました。 9月29日、当社のエンジニアは、メールゲートウェイ、それらが依存する内部サービス、およびネットワークレイヤー全体で、以前の日のデータを見直しました。 メールフローの遅延とコンソールアクセスの問題は、簡単に戻り、ネットワークトラフィックが減少し、同じパターンを9月28日と下回りました。 9月30日、約12時19分から12時35分までの間、当社のチームは、サービスが継続して米国ネットワークサービスの容量を増加させました。 2026年9月30日は、変更直後に積み下ろし、約12:35\(UTC\)で正常な性能に戻り、保護します。 9月30日と10月1日のピークトラフィックを監視し、再発が見つかりません。 この問題の結果としてデータ損失が発生しません。 ##**ルート原因** この問題は、米国郵便処理サービスのトラフィックを処理するネットワークサービスの容量制限によって引き起こされました。 ピークのトラフィック中、特に毎時スパイク中、ネットワークサービスは接続を十分に処理できませんでした。 これにより、トラフィックが通過し、いくつかの接続が低下する遅延が発生しました。 そのトラフィックには、メールゲートウェイが配布リストメンバーを調べるために送信する内部リクエストが含まれているため、適切なポリシーが適用されます。 これらの要求は厳密な時間制限の対象となるため、遅いルックアップはメール処理を無期限に保持できません。 ネットワークサービスがその制限を超えたリクエストを遅らせると、失敗した。 その結果、メール処理が遅くなり、メッセージがキューに入れられた。 問題が悪化し、識別しにくい2つの要因。 まず、内部のリクエストもネットワークサービスを利用し、容量制限の影響を受けました。 第二に、ネットワークサービスは、その計算が正常に問題に信号されるレベルに達する前に劣化し始めました。 標準的な計算監視はネットワークの飽和をキャッチしませんでした、従って原因はもはや識別するために取られた。 割込みサービスなしで容量を増加させる安全な方法を見つけることも時間がかかります。そのため、9月30日に修正が適用されました。 ##**緩和と是正** アメリカのネットワークサービスはピークトラフィックを処理する能力が十分になかったことを発見しました。 変化を通したサービスを続け、その能力を高めることで、これを緩和しました。 容量が増加した後、ネットワークサービスは、さらに問題なくピークトラフィックを処理しました。 また、ネットワークの飽和の信頼できる兆候ではなく、コンピューティング単独での使用も確認しました。 ネットワークヘルスインジケーターを追跡し、コンピュート使用に加えてモニタリングを拡大しました。 最後に、内部の要求が故障した箇所が見つかりませんでした。 内部リクエストが失敗し、タイムアウトした場所を示すログを追加しました。 ##**顧客への影響** 9月28日と29日の米国交通のピーク中、一部の顧客は、予防と保護を通じて、インバウンドおよびアウトバウンドメールの処理および配信の遅延を経験しました。 ディストリビューションリストにアドレスを付けられたメッセージは、検索時によりゆっくりと処理されることがあります。 一部の顧客は、米国コンソールにログインしたり、使用したりすることも断続的に困難でした。 米国のトラフィックが減少し、キャパシティが回復すると、毎日の影響が緩和され、キュートメールが処理されました。 9月30日の変更後、ピーク時に更なる劣化が見つかりません。 ##**予防措置** 今後、このタイプの問題を防ぐため、米国ネットワークサービスの容量を増加させ、ネットワークヘルスインジケーターを追跡し、コンピュート使用に加えて、モニタリングを拡大しました。 また、ログを追加し、可視性を改善し、内部の要求に失敗しました.
公式のインシデント更新を自動翻訳しています。
弊社では、劣化した性能が認められた「保護」の問題を特定し、当社のエンジニアリングチームは修正を検討しています.
劣化した性能で、Protec の問題を識別しました。 修正を実施し、引き続きこの問題を監視します.
弊社では、劣化した性能が認められた「保護・防護」の問題を特定し、当社のエンジニアリングチームは修正をしています.
修正を実装し、結果を監視しています.
この事件は解決しました.
##**概要** 2026年9月24日(木)から、約17:07\(UTC\)、9月25日(金)まで、約9:16\(UTC\)、一部の顧客は、米国防護インスタンスの断続的な減速、エラー、および遅延したメールフローを経験した。 9月24日、米国郵便処理のトラフィックを処理するネットワークサービスに、Eメールトラフィックに異常に大きなスパイクを配置しました。 モニタリングは、約17:07 \(UTC\)で警告しました。 一部の顧客は、ページや高度なオプションをロードするときに、保護および時々のエラーに遅いまたは断続的なアクセスを見た。 アクセスは矛盾していたので、他の人がエラーを見ている間、保護を使用することができる人もいます。 米国インスタンスによるメール処理が遅くなり、予想されるとモデレーション受信ボックスにメッセージが遅れたり、表示されないことがあります。 パフォーマンスが向上するため、ステータスページ通知を18:39\(UTC\)で監視に移しました。 再発後、サポートチームに引き続き遅くなると報告した。 19:57 年(UTC\) で、衝撃がより鮮明になるように防いでいくために、通知を調査し、拡大しました。 当社のチームは、影響を受けるシステムを監視し、高額のメールボリュームをサブサイドに監視しました。 ネットワークサービスの負荷が正常に戻り、メール処理が回復し、通常の一晩に返されたメールキュー。 保護が正常にロードされ、テストメッセージが再び配信されたことを確認し、監視を続けたことを確認しました。 2026年9月25日(水)の9時16分頃までに、通常の性能に戻り、防止します。 この問題の結果としてデータ損失が発生しません。 ##**ルート原因** この問題は、メールトラフィックの異常に大きなスパイクによって引き起こされました。 増加したボリュームは、米国のメール処理のためのトラフィックを処理するネットワークサービスに持続的な負荷を置く。 これらのネットワークサービスは、固定容量制限内で動作し、スパイク中に容量がスケールアップできませんでした。 彼らがサージで追いつくことができないので、彼らは減速し、いくつかの処理は断続的に失敗しました。 その結果、米国のメール処理で大量のメールがキューに入れられ、返されたエラーを保護するページやアクションがいくつかあり、予想されるとモデレーションの受信トレイにメッセージが遅れたり、表示されないことがあります。 2つの要因は、問題が管理しにくいようにしました。 まず、アクセスが断続的に失敗したため、顧客がエラーを見続けながら、一部のチェックが成功し、回復が確認し難しくなります。 第二に、当社の監視は、負荷がまだ上昇していたかどうかをリアルタイムで判断するのは困難だった電流負荷よりも、ネットワークサービスのピーク負荷を示しました。 ##**緩和と是正** USメール処理のネットワークサービスは、トラフィックのスパイク中に固定容量制限に達し、イベント中に容量が増加できなかったことを発見しました。 当社のチームは、影響を受けるシステムを監視し、高額のメールボリュームのサブサイドとネットワークサービス負荷が正常に戻りました。 メールでの処理が回復し、キュートメールが処理されました。 再発前に問題が改善されてきたので、事故を解決する前に、いくつかの方法で回復を確認しました。 保護は通常、米国郵便処理によりテストメッセージが配信され、サポートリクエストが正常に進行していると確認しました。 また、アメリカ国内の顧客から一晩監視し、新規のレポートを受け取りません。 ##**顧客への影響** 一部の顧客は、保護への遅くまたは断続的なアクセスを持っていたり、ページや高度なオプションをロードするときにエラーが時々見られたりしました。 米国インスタンスによるメール処理は、保護と防止のために遅れていました。 場合によっては、予想されると、メッセージが遅延したり、モデレーションの受信トレイに表示されないことがあります。 米国郵便処理を通過すると、メールが暗号化され、復号化、または適度に処理されるお客様は、影響を受ける可能性が高い。 ほとんどの場合、メール処理遅延の影響を受けていないアドオンを使用して顧客を保護します。 コンソールの動作が遅いメール処理によって影響されたものの、コンソールを保護し、防止します。 ##**予防措置** 将来的には、このタイプの問題を防ぐため、メールの音量で異常な増加のモニタリングを改善しています。 また、当社のモニタリングを改善し、ピーク値だけでなく、ネットワークサービスの現在の負荷を表示します。 また、突然のトラフィックのスパイク中にネットワーク容量をより動的にスケールアップし、米国郵便処理を処理するネットワークインフラへの長期的改善を評価する方法を評価しています。 また、米国ネットワークサービスの容量を「後続のインシデント」(https://status.knowbe4.com/incidents/9wc6rjm8g70v)に変更しました.
公式のインシデント更新を自動翻訳しています。
ログイン時に「アクセス拒否」エラーメッセージを受信したユーザーのレポートを受け取りました。 問題を特定し、解決策の実装に取り組んでおり、詳細はこのページを更新します.
問題が特定され、修正が実施され、詳細が記載されている場合はこのページを更新します.
このインシデントは正常に解決され、すべてのシステムが完全に運用されています.
公式のインシデント更新を自動翻訳しています。
一部のユーザーがWebフォームの送信を正常に送信できないと報告しています。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
問題が特定され、修正が実装されています。 より多くの情報の更新はそれに応じて続きます.
問題が特定され、修正が実施され、詳細が記載されている場合はこのページを更新します.
このインシデントは正常に解決され、すべてのシステムが完全に運用されています.
2026年9月23日(水)は、約815〜11:18\(UTC\)で、一部の顧客は、セキュアなWebフォームの英国インスタンスで遅いと失敗したフォームの送信を経験しました。 この問題は、最近の変化に続く英国生産環境におけるデータベースのパフォーマンス制限によって引き起こされました。 データベースの設定は、非効率で実行するクエリも発生しました。 その結果、応答時間が増加し、フォームの送信が失敗しました。 この問題を解決するために、当社のチームは一時的にバックグラウンド同期タスクを使用して、負荷を軽減し、クエリの効率を改善し、ストレージのスループットを増加させました。 セキュアなWebフォームは、11:18\(UTC\)で通常のパフォーマンスに戻りました。 今後、このタイプの問題を防ぐため、データベース帯域幅の追加監視を追加しています。 背景同期タスクの効率性も向上しています。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
英国地域でのWebアクセス(Secure Message Portal)によるメール送信ができないというレポートを受け取り、「503 Service Unavailable」というエラーが出ました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
修正を実施し、結果を監視しています.
今後の問題がないか引き続き監視しています。
このインシデントは正常に解決され、すべてのシステムが完全に運用されています.
2026年9月21日(月)から、約855(火)から9月22日(火)まで、約14:30\(UTC\)で、一部のユーザーはエラーが発生し、英国地域でWebアクセス\(Secure Message Portal\)を介してメールを送ることができませんでした。 このインシデントは、データベースの更新中に設定エラーによって引き起こされ、断続的なサービスの中断を引き起こしました。 この問題を解決するためには、設定を反転し、Web Accessは9月22日(月)14:30\(UTC\)で通常のパフォーマンスに戻りました。 今後、このタイプの問題を防ぐため、データベースの設定を見直し、更新しています。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
KSAT の DE と UK インスタンスにログインできないというレポートを受け取りました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
この事件は解決しました.
##**概要** 2026年9月17日、バックグラウンドジョブは大きなユーザーグループをアーカイブし、単一のアンバウンドされたデータベーストランザクションとして実行しました。 このトランザクションは多数のユーザ行をロックし、同じテーブルに書き込むため、米国地域のログインをタイムアウトさせています。 プラットフォームの実行制限を打つと、ジョブが終了し、自動的に15分間隔で5回取得し、75分の停電が発生しました。 課題を解決するため、ロックからデカップリングされたログインを解除する修正をデプロイしました。 その後、ログイン変更によって導入された回帰のためのフォローアップ修正、ならびにアーカイブジョブをデプロイしました。 ## **何が起こっているか** 以前の変更は、同期、タイムアウトのWebリクエストから「すべてのユーザーをアーカイブ」アクションをアンバウンドしたバックグラウンドジョブに移動しました。 大規模なユーザーグループがアーカイブされたとき、これは新しい背景ジョブをトリガーしました。 ジョブは、すべての影響を受けるユーザ行を単一のトランザクションでロックし、パーユーザの書き込みとコミットする前に同期外部サービスコールを実行します。 同じテーブルに書いてあるログインの試みは、ロックされたジョブの後ろにキューに入れられ、米国のユーザーのためにタイムアウトしました。 ジョブが15分のプラットフォームの実行制限に達したとき、トランザクションはトランザクションがロールバックされ、ジョブはキューに赤化されました。 このサイクルは5回発生し、75分の停電が発生しました。 故障が内部で22:35\(UTC\)で検出されたとき、事故が宣言され、エンジニアが対応するページが作成されました。 ログインフローから書き込みアクションをデカップリングする緩和は、約23:44\(UTC\)で展開されました。 緩和自体は、回帰を引き起こしました: 以前にパスワードを誤った任意の領域の任意のユーザは、失敗したログインの試みが読み取り専用のデータベースに書き込みしようとしたため、ログインをリセットすることができませんでした。 2026年9月18日(火)に09:17\(UTC\)で、この回帰の修正が地域全体に展開されました。 正式な修正前の米国唯一のアーカイブジョブの問題は、13:45と14:05 \(UTC\)の2回以上再発しました。 2026年9月18日には、19:12円(UTC\)で事件を解決しました。 ##**ルート原因** 多くの影響を受けた行に排他的なロックを保持し、大規模なグループユーザー アーカイブのための無向の単一トランザクションの背景ジョブ、ログイン プロセスの独自の行の書き込みをブロックします。 この操作をWebリクエストのタイムアウトとバックグラウンドジョブに移動する前の変更は、その期間の残りの制限のみを削除しました。 プラットフォームの15分の実行制限をトリガーし、自動キルアンドレディバサイクルをトリガーし、ロックのコンピジョンを5回繰り返すと75分の停電ウィンドウになります。 ##**Findings と Mitigations** 未登録のアーカイブトランザクションは、影響を受けるユーザー列の多数をロックし、他のテーブルの書き込みをブロックしたことを発見しました。 これは、ログインプロセスの書き込み依存性を影響を受けたテーブルからデカップリングすることで短期的に緩和され、その後、アーカイブジョブを修正することにより、長期的に固定されました。 また、作業員のコンポレーションがロックのコンポレーションを増幅していることがわかりました。 これは、作業員の対立性を手動で削減することによって、短期間で軽減されました。 これらのジョブをstagger に固定し、シリアライズする長期的な修正が計画されています。 最後に、ログイン・フィックス・レグレッションは、読み取り専用のデータベースで書き込みが拒否されたため、ユーザーが失敗した試みで、すべてのレギオン・ログインの失敗を引き起こしました。 これは、すべての地域で展開および検証された標的コード変更を介して固定された。 ##**予防措置** 私たちは、それらをバインドし、それらを処理し、小さな、コミットされたバッチを処理し、データベーストランザクションの外部の呼び出しを維持することによって、大規模なグループアーカイブの操作を改善しています。 また、変更チェックを特定のバックグラウンドワーカーに追加して、何も変更しない書き込みをスキップします。 最後に、定期的な間接チェックに加えて、データベーストランザクションの年齢と購入遅延の直接アラートを追加します。 ##**顧客への影響と回復** 米国の地域で約75分遅れたログイン障害。 2つの簡単なと、米のみ再発が翌朝起き、数分で手動で消去されました。 ユーザー管理などの管理者行動も影響を受けました。 パートナーのログインが不備でした。 二次回帰は約10時間持続し、以前にログインの試みを失敗したユーザーのすべての地域に影響しました。 9月18日の午後、全地域に完全回復が確認され、ステータスページが解決しました。 この問題の結果としてデータ損失が発生しません。 ## **結論** 単一の非結合の背景トランザクション、自動再試行メカニズムと組み合わせ、米国の地域でのログイン不足を引き起こします。 特定のトリガージョブとその再試行の動作が修正され、終了した書き込みパスに依存しません。 同じインシデントの回帰と2つのマイナーな再発は、それぞれ時間内に解決しました。 作業者の調整やデータベースのトランザクション監視など、予防的な作業を再開します.
公式のインシデント更新を自動翻訳しています。
ユーザーがKSATのUSインスタンスにログインできないというレポートを受け取りました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
修正を実装し、結果を監視して、さらなる問題が起きないようにします.
KSAT の米国インスタンスにログインできないユーザの新規レポートを受け取りました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
この事件は解決しました.
##**概要** 2026年9月17日、バックグラウンドジョブは大きなユーザーグループをアーカイブし、単一のアンバウンドされたデータベーストランザクションとして実行しました。 このトランザクションは多数のユーザ行をロックし、同じテーブルに書き込むため、米国地域のログインをタイムアウトさせています。 プラットフォームの実行制限を打つと、ジョブが終了し、自動的に15分間隔で5回取得し、75分の停電が発生しました。 課題を解決するため、ロックからデカップリングされたログインを解除する修正をデプロイしました。 その後、ログイン変更によって導入された回帰のためのフォローアップ修正、ならびにアーカイブジョブをデプロイしました。 ## **何が起こっているか** 以前の変更は、同期、タイムアウトのWebリクエストから「すべてのユーザーをアーカイブ」アクションをアンバウンドしたバックグラウンドジョブに移動しました。 大規模なユーザーグループがアーカイブされたとき、これは新しい背景ジョブをトリガーしました。 ジョブは、すべての影響を受けるユーザ行を単一のトランザクションでロックし、パーユーザの書き込みとコミットする前に同期外部サービスコールを実行します。 同じテーブルに書いてあるログインの試みは、ロックされたジョブの後ろにキューに入れられ、米国のユーザーのためにタイムアウトしました。 ジョブが15分のプラットフォームの実行制限に達したとき、トランザクションはトランザクションがロールバックされ、ジョブはキューに赤化されました。 このサイクルは5回発生し、75分の停電が発生しました。 故障が内部で22:35\(UTC\)で検出されたとき、事故が宣言され、エンジニアが対応するページが作成されました。 ログインフローから書き込みアクションをデカップリングする緩和は、約23:44\(UTC\)で展開されました。 緩和自体は、回帰を引き起こしました: 以前にパスワードを誤った任意の領域の任意のユーザは、失敗したログインの試みが読み取り専用のデータベースに書き込みしようとしたため、ログインをリセットすることができませんでした。 2026年9月18日(火)に09:17\(UTC\)で、この回帰の修正が地域全体に展開されました。 正式な修正前の米国唯一のアーカイブジョブの問題は、13:45と14:05 \(UTC\)の2回以上再発しました。 2026年9月18日には、19:12円(UTC\)で事件を解決しました。 ##**ルート原因** 多くの影響を受けた行に排他的なロックを保持し、大規模なグループユーザー アーカイブのための無向の単一トランザクションの背景ジョブ、ログイン プロセスの独自の行の書き込みをブロックします。 この操作をWebリクエストのタイムアウトとバックグラウンドジョブに移動する前の変更は、その期間の残りの制限のみを削除しました。 プラットフォームの15分の実行制限をトリガーし、自動キルアンドレディバサイクルをトリガーし、ロックのコンピジョンを5回繰り返すと75分の停電ウィンドウになります。 ##**Findings と Mitigations** 未登録のアーカイブトランザクションは、影響を受けるユーザー列の多数をロックし、他のテーブルの書き込みをブロックしたことを発見しました。 これは、ログインプロセスの書き込み依存性を影響を受けたテーブルからデカップリングすることで短期的に緩和され、その後、アーカイブジョブを修正することにより、長期的に固定されました。 また、作業員のコンポレーションがロックのコンポレーションを増幅していることがわかりました。 これは、作業員の対立性を手動で削減することによって、短期間で軽減されました。 これらのジョブをstagger に固定し、シリアライズする長期的な修正が計画されています。 最後に、ログイン・フィックス・レグレッションは、読み取り専用のデータベースで書き込みが拒否されたため、ユーザーが失敗した試みで、すべてのレギオン・ログインの失敗を引き起こしました。 これは、すべての地域で展開および検証された標的コード変更を介して固定された。 ##**予防措置** 私たちは、それらをバインドし、それらを処理し、小さな、コミットされたバッチを処理し、データベーストランザクションの外部の呼び出しを維持することによって、大規模なグループアーカイブの操作を改善しています。 また、変更チェックを特定のバックグラウンドワーカーに追加して、何も変更しない書き込みをスキップします。 最後に、定期的な間接チェックに加えて、データベーストランザクションの年齢と購入遅延の直接アラートを追加します。 ##**顧客への影響と回復** 米国の地域で約75分遅れたログイン障害。 2つの簡単なと、米のみ再発が翌朝起き、数分で手動で消去されました。 ユーザー管理などの管理者行動も影響を受けました。 パートナーのログインが不備でした。 二次回帰は約10時間持続し、以前にログインの試みを失敗したユーザーのすべての地域に影響しました。 9月18日の午後、全地域に完全回復が確認され、ステータスページが解決しました。 この問題の結果としてデータ損失が発生しません。 ## **結論** 単一の非結合の背景トランザクション、自動再試行メカニズムと組み合わせ、米国の地域でのログイン不足を引き起こします。 特定のトリガージョブとその再試行の動作が修正され、終了した書き込みパスに依存しません。 同じインシデントの回帰と2つのマイナーな再発は、それぞれ時間内に解決しました。 作業者の調整やデータベースのトランザクション監視など、予防的な作業を再開します.
公式のインシデント更新を自動翻訳しています。
英国のインスタンスでアカウントのログインとアクセスの問題を引き起こした問題を特定しました.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
Septermber 8th では、インバウンド HTML 電子メールが 部分的にレンダリングされたか、古典的な Outlook で空白になっていることを認識しました。 Defend の有害なコード削除エンジンで HTML ライブラリのアップグレードが、古典的な Outlook のレガシーワードレンダリングエンジンと相互作用しています。 Web上の新しいOutlookとOutlookは影響を受けていませんでした. これは、厳密に表示の問題でした:メールが遅延、紛失、または侵害されず、脅威の検出は完全にアクティブのままでした。 エンジニアリングは、通常のレンダリングを復元するために更新を反転しました。 万一、この窓に有害なコード除去を無効にされている場合は、完全な保護を確実にするために再有効にしてください.
公式のインシデント更新を自動翻訳しています。
ワークスペースのメール検証MFAの配信に伴う問題の報告をいただきました。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
ワークスペースのメール検証MFAの配信に関する問題がMicrosoftによって緩和されていると報告し、結果の監視を行っています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
ユーザーが処理中のメッセージの遅延を経験する可能性がある問題を特定し、エンジニアリングチームは修正を検討しています.
弊社のエンジニアリングチームは、PishER のメッセージ処理遅延を引き起こし、その結果を監視している問題の修正を行いました.
当社のエンジニアリングチームは、PishER でメッセージ処理遅延を引き起こしている問題の修正を行いました.
##**概要** 2026年8月26日にルーチン展開中、インフラ管理フレームワークは、処理できないメッセージを保持する主要なメッセージ処理キューと二次キューの両方を予期せず削除しました。 これにより、PishER顧客の受信トレイにメール配信を差し込む一時的な中断が発生しました。 この問題の結果としてデータ損失が発生しません。 ##**ルート原因** 2026年8月24日、内部構成変更は、コードと同期して残ったライブ構成レコードを変更します。 後続のコード更新はレコードを反転させなかった。 ルーチンの生産展開が2026年8月26日に実行されると、アクティブな構成コードには、再配置されたリソースレコードが含まれていません。 その結果、展開は、未管理のリソースとしてアクティブなキューを処理し、それらを削除しました。 ##**緩和と是正** 自動監視は、メッセージ処理の低下に警告し、インシデントレスポンスチームを組み立てました。 キューが削除されたことがわかりました。 これは、影響を受けた生産ジョブを再実行することにより、不足しているキューを再作成することにより、短期的に緩和されました。 リアルタイムメール処理が再開されたことを確認しました。 最後に、お客様の受信トレイに停電時にクラウドストレージで保持されているメールペイロードを再再生しました。 ##**タイムライン** UTCには常にあります。 * ** 8月 24, 2026, 18:41:** 内部構成の変更は、更新されたリソースレコードをライブ生産構成に書きました。 * ** 8月 26, 2026, 15:15** 生産展開は、インバウンドキューと、生産で処理できないメッセージを保持するキューを削除し、メール配信を顧客の受信トレイに停止します。 * ** 8月 26, 2026, 15:59** 自動化されたモニタリングにより、エンジニアリングチームが処理中のメッセージをゼロにし、インシデントレスポンスチームをページ化しました。 * ** 8月 26, 2026, 16:01:** キューを削除し、メールのペイロードが安全に保存されたことを確認しました。 * ** 8月 26, 2026, 16:15** 第一次根本原因として構成の不一致を識別しました。 * ** 8月 26, 2026, 16:25 ** 当社のチームは、影響を受けた生産ジョブを再実行し、キューを再作成しました。 * ** 8月 26, 2026, 18:44 ** 当社の自動再生は、顧客の受信トレイにすべてのバックロックされたメールを配信終了しました。 ##**予防措置** 将来的には、このタイプの問題を防ぐため、あらかじめマージチェックと生産変更から分離された展開計画から、ライブコンフィギュレーションステップを削除しました。 また、リリース完了後にキューヘルスを確認するための自動チェックを追加しました。 ##**顧客への影響** 2026年8月26日の15:15から16:25まで、PishERに提出されたメールは、顧客の受信トレイに処理されませんでした。 インバウンドメールのペイロードは、混乱を通じてクラウドストレージで安全に保存されました。 キューが復元された後、自動再生は顧客の受信トレイに電子メールを保有しました。 18:44\(UTC\) が返送されました。 この問題の結果として、顧客メールデータは失われませんでした.
公式のインシデント更新を自動翻訳しています。
Gmail Phish Alert ボタンがエラー「[reportPhishAttempt()] を示すレポートを受け取りました。 内部エラーが発生しました。 phishを報告するときは、もう一度お試しください。 この問題を調査し、より多くの情報を持っているときにこのページを更新します.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
2026年8月21日(金)、約05:20から12:55まで、Gmail Phish Alert button add-inを使用して疑わしいメールを報告する際、一部の顧客は断続的な失敗を経験しました。 問題は、EU-WestとUS-Eastのサービス領域に集中した最高のエラー量で、すべての地域で顧客に影響を与える。 この問題は、GoogleのApps Scriptプラットフォーム上のキャッシュサービスの中断によって引き起こされました。これにより、アドインはユーザーセッションの設定ごとに保存されます。 本サービスは、新しい文章をまだ受け入れながら、読み込まれた空の結果を断続的に返し始め、影響を受けた報告投稿が失敗するようになりました。 KnowBe4は直接Googleを従事し、約12:19と12:39 \(UTC\)の間の正式なバグ報告を提出しました。 エラーボリュームは、ベンダー側の状態がクリアされた後、急激に減少し、Gmail Phish Alert ボタンは、約12:55\(UTC\)で通常のパフォーマンスに戻りました。 将来的には、このタイプの問題を防ぐため、根本的なキャッシュ欠陥の解像度を追跡するためにGoogleと連携し続けています。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
Phish Alert ボタンと「Send Us a Copy」がアカウント設定で有効になっているときにメッセージが報告されると、非配信レポート (NDR) が返される問題を修正しました
修正を実装し、結果を監視しています.
この事件は解決しました.
2026年8月18日(火)、約14:10から14:55まで、Pish Alert button \(PAB\) を使っているお客様は、**Send Us a Copy** 機能が、**Send Us a Copy**メールボックスの非配達レポートを受信しました。 この問題は、共有メールルーティングインフラストラクチャへの構成変更によって引き起こされました。 この変更は、ステージングと生産環境の両方で使用されるメッセージングコンポーネントの名前を変更しました。 生産ルールは、この共有コンポーネントに依存しているため、Rename は、*Send Us a Copy** のメールボックスに配送障害を引き起こし、非配達レポートをトリガーしました。 この問題を解決するために、影響を受けた構成を更新して正しいコンポーネントを参照し、**Send Us a Copy**機能は14:55 \(UTC\)で通常のパフォーマンスに戻りました。 今後このタイプの問題を防ぐため、ステージングや生産環境のメールルーティング設定を分離しています。 既存の構成を現在のインフラ管理基準に再構成しています。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.
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.
Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.
SAT コンソールのロードからアカウント設定を防ぐ問題を特定しました.
修正を実装し、結果を監視しています.
この事件は解決しました.
火曜日、8月4、2026、約18:22から19:43の\(UTC\)、一部の顧客は、CA、DE、EU、イギリス、および米国の地域を横断する既知Be4コンソールで**アカウント設定**ページをロードする問題を経験しました。 この問題は、アカウント設定の経験で使用されるGraphQLリクエストの複雑性を高める一連のアプリケーション変更によって引き起こされました。 各変更は、プラットフォームの構成された複雑さのしきい値の下に個別に評価されますが、組み合わせて、要求は、そのしきい値を超えており、ページの読み込みを防止しました。 エンジニアリングは、コントリビューション要因として複雑さのしきい値を特定し、約19:14 \(UTC\)で始まる正しい変化を展開しました。 患部全体で修正が確認された後、既知のBe4コンソールは19:43円(UTC\)で通常のパフォーマンスに戻りました。 今後この問題を防ぐため、複雑さの閾値が増加しました。 この問題の結果としてデータ損失が発生しません.
公式のインシデント更新を自動翻訳しています。
PhishRIP が予期せぬメールに関連した問題を調査しています
この問題では修正が実装され、PishRIP のクエリは、予期しないと宣言されたメッセージには適用されません。 影響を受けている可能性のある質問はまだ調査中です
この事件は解決しました.
##**概要** 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 \(正規表現\):** ソフトウェアで使用されているパターンは、メールアドレスが正しくフォーマットされていることを確認し、テキストを検索し、入力を検証します。 * ** コードの逆転:** ソフトウェアの更新をバックアップして、以前の安定したバージョンに戻します.
公式のインシデント更新を自動翻訳しています。
弊社では、ストアの「保護ライセンス」の購入ができないユーザーを調査しています。knowbe4.com 詳細については、このページを更新いたします.
修正を実装し、結果を監視して、さらなる問題が起きないようにします.
お客様がストアでProtecライセンスを購入できないという報告をいただきました。knowbe4.com. この問題を調査し、より多くの情報を持っているときにこのページを更新します.
オンラインストアの修正を実装し、さらなる問題が起こらないよう結果を監視しています.
今後もオンラインショップの修正を継続的に監視し、さらなる問題が起こらないように努めてまいります.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。