KnowBe4 Outage History

On Tuesday, March 31, 2026, from approximately 15:00 \(UTC\) to 16:10 \(UTC\), some users experienced issues with the Defend Abuse Mailbox service. This incident was caused by a service update that started sending duplicate phishing submission notifications to users. To resolve this issue, we corrected the service update code that caused the duplicate notifications, and the Defend Abuse Mailbox service returned to normal performance by 16:10 \(UTC\). To prevent this type of issue in the future, we are reviewing and improving our service upgrade workflow. No data loss occurred as a result of this issue.

On Thursday, March 19, 2026, from approximately 11:56 \(UTC\) until 13:14 \(UTC\), some UK users experienced intermittent issues while attempting to log in to Prevent and Protect consoles. This incident was caused by a configuration timeout in our session management system. To resolve this issue, we increased the timeout limit, and the Prevent and Protect consoles returned to normal performance by 13:14 \(UTC\). To prevent this type of issue in the future, we have improved our timeout monitoring process and are verifying configuration consistency and optimization across our environments. No data loss occurred as a result of this issue.

From Tuesday, March 17, 2026, at approximately 16:00 \(UTC\), to Wednesday, March 18, 2026, at approximately 13:00 \(UTC\), some users experienced errors while submitting Workspace webforms. This incident was caused by a configuration error during a domain migration. To resolve this issue, we corrected the domain configuration, and webform submissions returned to normal performance by 13:00 \(UTC\) on March 18, 2026. To prevent this type of issue in the future, we are reviewing and updating our domain migration process. No data loss occurred as a result of this issue.

On Thursday, March 5, 2026, from approximately 02:20 until 03:10 \(UTC\), some customers experienced expired SSL certificate warnings when accessing their Defend and Prevent admin consoles. This incident was caused by an expired certificate for an internal service. To resolve this issue, we deployed a new certificate and updated all affected instances. The Defend and Prevent consoles returned to normal performance by 03:10 \(UTC\). To prevent this type of issue in the future, we are improving our certificate monitoring. No data loss occurred as a result of this issue.

On Tuesday, February 10, 2026, from approximately 13:57 to 16:01 \(UTC\), some users experienced delays with the integration service on the EU instance of the PhishER console. This incident was caused by a system upgrade that unexpectedly affected the integration service, causing errors in the production environment. To resolve this issue, we reverted the update, and the PhishER console returned to normal performance by 16:01 \(UTC\). No data loss occurred as a result of this issue.

On Tuesday, February 10, 2026, customers in the UK region began experiencing upload delays with Workspace at approximately 11:01 \(UTC\), due to instability within a messaging node. The node was isolated at 12:20 \(UTC\) to protect cluster integrity and was successfully reintegrated at 13:40 \(UTC\), restoring normal upload processing shortly after. Beginning at approximately 12:10 \(UTC\), a subset of Workspace instances across multiple regions became slow or temporarily unresponsive due to memory exhaustion on their underlying virtual machines. As each Workspace instance operates independently, the impact varied by customer. To resolve this issue, we identified and progressively redeployed the affected instances, starting at 14:37 \(UTC\), with the majority restored shortly after. The final affected instance was confirmed healthy at 19:27 \(UTC\). Our analysis confirmed that abnormal memory consumption by the Azure Monitoring Agent caused the host memory exhaustion observed on impacted instances. An infrastructure update scan occurred earlier that morning, at 08:22 \(UTC\). Current evidence indicates that this scan triggered an underlying defect in the monitoring agent. The scan itself was non-disruptive in design and was a platform security procedure, not intended as a customer-impacting maintenance activity. We confirmed that all systems were stable on February 10 and completed a deep review of data validation on February 11, 2026. No data loss or security compromise occurred. To prevent this type of impact in the future, we are strengthening monitoring safeguards around host memory behaviour, enhancing messaging cluster resilience, reinforcing update governance controls, and formalising rapid restoration procedures.

On Wednesday, February 4, 2026, from approximately 15:30 to 16:00 \(UTC\), some US users experienced email delivery delays in the Defend product. This issue was caused by a brief networking fluctuation, resulting in email delivery delays of up to 10 minutes during the affected period. Once the cloud environment returned to healthy operating levels, Defend returned to normal performance, and all delayed emails were delivered by 16:00 \(UTC\). No data loss occurred as a result of this issue.