KnowBe4 Outage History

Started Jun 24, 2026, 03:48 PM UTC· resolved Jun 25, 2026, 01:10 PM UTC

1. investigating Jun 24, 2026, 03:48 PM UTC

   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. monitoring Jun 24, 2026, 10:06 PM UTC

   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. resolved Jun 25, 2026, 01:10 PM UTC

   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. postmortem Aug 04, 2026, 02:50 PM UTC

   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.

Read the full incident report →

Started Jun 18, 2026, 09:14 PM UTC· resolved Jun 19, 2026, 02:01 PM UTC

1. investigating Jun 18, 2026, 09:14 PM UTC

   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. investigating Jun 18, 2026, 09:16 PM UTC

   We are continuing to investigate this issue.

3. monitoring Jun 18, 2026, 10:42 PM UTC

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

4. resolved Jun 19, 2026, 02:01 PM UTC

   This incident has been resolved.

5. postmortem Jul 07, 2026, 07:45 PM UTC

   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.

Read the full incident report →

Started Jun 18, 2026, 03:13 PM UTC· resolved Jun 18, 2026, 07:12 PM UTC

1. investigating Jun 18, 2026, 03:13 PM UTC

   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. monitoring Jun 18, 2026, 03:43 PM UTC

   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. resolved Jun 18, 2026, 07:12 PM UTC

   This incident has been resolved.

4. postmortem Sep 08, 2026, 03:44 PM UTC

   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.

Read the full incident report →

Started Jun 16, 2026, 10:23 PM UTC· resolved Jun 17, 2026, 08:19 PM UTC

1. investigating Jun 16, 2026, 10:23 PM UTC

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

2. monitoring Jun 17, 2026, 12:48 PM UTC

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

3. resolved Jun 17, 2026, 08:19 PM UTC

   This incident has been resolved.

4. postmortem Aug 21, 2026, 06:00 PM UTC

   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.

Read the full incident report →

Started Jun 15, 2026, 04:56 PM UTC· resolved Jun 15, 2026, 04:56 PM UTC

1. resolved Jun 15, 2026, 04:56 PM UTC

   This incident has been resolved.

2. postmortem Aug 20, 2026, 07:41 PM UTC

   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.

Read the full incident report →

Started Jun 03, 2026, 03:07 PM UTC· resolved Jun 03, 2026, 06:14 PM UTC

1. investigating Jun 03, 2026, 03:07 PM UTC

   We have received reports of 500 errors occurring when navigating to user profiles. We are investigating this issue and will update this page when we have more information.

2. monitoring Jun 03, 2026, 04:16 PM UTC

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

3. resolved Jun 03, 2026, 06:14 PM UTC

   This incident has been resolved.

4. postmortem Jul 15, 2026, 03:23 PM UTC

   On Wednesday, June 3, 2026, from approximately 14:49 to 16:09 \(UTC\), customers experienced errors when accessing the **User Details** page in the KSAT console. This issue was caused by an update that introduced missing fields, which prevented the **User Details** page from loading. To resolve this issue, our team updated the console again to restore the missing fields, and the KSAT console returned to normal performance by approximately 16:09 \(UTC\). To prevent similar issues in the future, additional automated tests were added. No data loss occurred as a result of this issue.

Read the full incident report →

Started May 28, 2026, 06:17 PM UTC· resolved May 28, 2026, 07:13 PM UTC

1. investigating May 28, 2026, 06:17 PM UTC

   We are currently investigating an issue preventing customers from uploading custom content to the new Modstore

2. resolved May 28, 2026, 07:13 PM UTC

   We have identified an issue with uploading custom content to the new Modstore and implemented a fix. Customers should be able to upload custom content successfully.

3. postmortem Jul 07, 2026, 07:43 PM UTC

   On Thursday, May 28, 2026, from approximately 18:07 to 18:57 \(UTC\), some customers experienced issues uploading custom content to the new ModStore in KnowBe4 Security Awareness Training \(KSAT\). This issue was caused by an update to the new ModStore that disabled the language selection field in the “Add Translation” upload step, preventing customers from completing that required part of the upload process. To resolve this issue, our engineering team identified the recent deployment responsible for the defect, corrected it, and deployed the update to production. KSAT returned to normal performance by 18:57 \(UTC\). To prevent this type of issue in the future, we are improving test coverage for the affected upload flow and adding automated checks to catch similar issues before they reach production. No data loss occurred as a result of this issue.

Read the full incident report →

Started May 27, 2026, 10:05 AM UTC· resolved May 27, 2026, 03:44 PM UTC

1. investigating May 27, 2026, 10:05 AM UTC

   We have received reports that there is a Intermittent issue sending emails for Protect. We are investigating this issue and will update this page when we have more information.

2. monitoring May 27, 2026, 02:39 PM UTC

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

3. resolved May 27, 2026, 03:44 PM UTC

   This incident has been resolved.

4. postmortem Sep 16, 2026, 01:47 PM UTC

   On Wednesday, May 27, 2026, from approximately 09:22 to 15:24 \(UTC\), some UK customers experienced intermittent issues with outbound email delivery in Protect. This issue was caused by a configuration change that disrupted outbound email processing. Affected emails failed to send and were instead held in a delivery queue. To resolve this issue, our team temporarily rerouted traffic while investigating the root cause and then updated the affected configuration. After the configuration was updated, all queued messages were delivered, and Protect returned to normal performance by 15:24 \(UTC\). To prevent this type of issue in the future, we are integrating the configuration update into future deployments. We are also improving monitoring to detect similar disruptions more quickly. No data loss occurred as a result of this issue.

Read the full incident report →

Started May 21, 2026, 01:40 PM UTC· resolved May 21, 2026, 05:20 PM UTC

1. identified May 21, 2026, 01:40 PM UTC

   We've received reports that customers are unable to access the new Modstore experience and are receiving 500 errors. We are investigating these issues and will update this page when we have more information.

2. monitoring May 21, 2026, 01:41 PM UTC

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

3. resolved May 21, 2026, 05:20 PM UTC

   This incident has been resolved.

4. postmortem Jul 07, 2026, 03:32 PM UTC

   # **Summary** On Wednesday, May 21, 2026, customers using the new ModStore experience within KnowBe4 Security Awareness Training \(KSAT\) were unable to access the ModStore and received HTTP 500 errors. The disruption affected all regional instances and lasted approximately 23 minutes, from 13:17 to 13:40 \(UTC\). This issue was caused by a defective code change in a routine ModStore deployment. The deployment itself completed successfully, but the change caused the application to return server errors when customers attempted to load the new ModStore. Our engineering team identified the faulty deployment within minutes, rolled it back, and confirmed full restoration of service at 13:40 \(UTC\). Only the new ModStore experience was affected. Customers using the classic ModStore, and all other KSAT functionality — including training assignments, campaigns, and reporting — remained fully operational throughout. There was no data loss as a result of this incident. # **What Happened** ## **New ModStore \(KSAT\)** At 13:08 \(UTC\) on May 21, 2026, a routine deployment of the new ModStore application began and was completed successfully across all production environments at 13:17 \(UTC\). The release included changes related to integrating the new ModStore natively into the KnowBe4 platform. Immediately following the deployment, the new ModStore began returning HTTP 500 errors to customers attempting to access it. At 13:28 \(UTC\), internal reports of the errors reached the engineering team, and by 13:30 \(UTC\) engineers had correlated the failures with the deployment. The decision to roll back was made at 13:31 \(UTC\). At 13:32 \(UTC\), with multiple customer support tickets confirming customer-facing impact, a high-severity incident was declared, and on-call engineers were contacted. The team quickly confirmed the scope: only the new ModStore experience, enabled for approximately half of customers plus those who had opted in, was affected, across all regional instances. The classic ModStore and all other KSAT functionality remained available. A rollback to the previous stable version was initiated at 13:35 \(UTC\) and completed at 13:40 \(UTC\), at which point access to the new ModStore was fully restored. Our public status page was updated at 13:40 \(UTC\) and moved to “Monitoring” one minute later. During the post-restoration investigation, an engineer noted that a separate infrastructure-as-code deployment earlier that morning had unexpectedly altered a storage Cross-Origin Resource Sharing \(CORS\) configuration used by the ModStore. This change was investigated as a potential contributor and ruled out — it was not related to the 500 errors. The investigation did, however, surface that two separate deployment pipelines were both managing the same infrastructure configuration and silently overwriting each other’s changes. This conflict was remediated during the incident window by assigning the configuration a single owning pipeline. After continued monitoring confirmed stability, the incident was resolved internally at 14:52 \(UTC\), and the public status page was updated to “Resolved” at 17:20 \(UTC\). # **Root Cause Analysis** The root cause of this incident was a defective code change included in the 13:17 \(UTC\) deployment of the new ModStore application. Once deployed, the change caused the application to fail to serve customer requests, returning HTTP 500 errors to all users of the new ModStore experience across all regions. The defect was not detected during pre-deployment testing, so the deployment proceeded to production as usual. Because the failure began at the moment the deployment completed and affected all regions simultaneously, engineers were able to identify the deployment as the trigger within minutes and end customer impact by rolling back to the previous version. The faulty change was withheld for rework and additional validation before any reintroduction. A secondary issue was identified during the investigation: an unrelated infrastructure configuration change that morning initially appeared connected because of its timing. It was ruled out as a cause, but the investigation revealed that two deployment pipelines shared ownership of the same infrastructure configuration and were overwriting each other. While this did not cause the incident, it added noise to the diagnosis. Because it represented a latent risk, it was also corrected the same day. ## **Detailed Timeline \(UTC\)** | **Time \(UTC\)** | **Event** | | --- | --- | | **13:08** | A routine deployment to the new ModStore application begins. | | **13:17** | The deployment completes across all production environments; HTTP 500 errors begin for the new ModStore experience. | | **13:28** | Internal reports of errors loading the new ModStore reach the engineering team. | | **13:30** | Engineers correlate the HTTP 500 errors with the earlier deployment. | | **13:31** | Decision made to roll back the deployment. | | **13:32** | A high-severity incident is declared; on-call engineers are paged. Customer support tickets confirm customer-facing impact. | | **13:33 – 13:34** | Impact confirmed to be limited to the new ModStore experience; the classic ModStore and all other KSAT functionality are confirmed unaffected. All regional instances are affected. | | **13:35 – 13:38** | The revert is prepared, and the rollback deployment begins. | | **13:40** | Rollback completes, and access to the new ModStore is restored. The public status page is updated to “Identified.” | | **13:41** | The public status page is updated to “Monitoring.” | | **13:58 – 14:11** | An unrelated same-morning infrastructure configuration change is investigated and ruled out as a cause. A conflicting ownership issue between two deployment pipelines that manage the same configuration is identified and remediated. | | **14:52** | After continued monitoring confirms stability, the incident is marked resolved internally \(74 minutes after the incident was declared\). | | **17:20** | The public status page is updated to “Resolved.” | ‌ # **Findings and Mitigations** ## **1. A defective change reached production** A code change included in a routine deployment of the new ModStore caused the application to return server errors in production. The defect was not caught by the automated tests that run before a release is promoted, indicating a gap in pre-deployment test coverage for this failure mode. **Mitigations:** * The deployment was rolled back within 23 minutes of impact beginning, immediately restoring service. * The faulty change was withheld from redeployment pending rework and additional validation. * Pre-deployment test coverage for the new ModStore is being expanded to cover the failure mode seen in this incident. ## **2. Detection relied on human reports rather than automated alerting** Impact began at 13:17 \(UTC\), but the engineering team was first engaged through internal reports at 13:28 \(UTC\) and customer support tickets shortly after, rather than by an automated alert on the application’s error rate. Automated post-deployment checks that ran after the release did not halt the rollout or page the team. **Mitigations:** * Error-rate monitoring and automated alerting for the new ModStore are being strengthened so that a spike in server errors immediately after a deployment pages the on-call team directly. * Post-deployment verification is being reviewed so that failing checks more decisively block or flag a release. ## **3. Two deployment pipelines managed the same infrastructure configuration** The application’s deployment pipeline and a separate infrastructure-as-code pipeline both defined the same storage CORS configuration, and each deployment silently overwrote the other’s settings. This conflict was not the cause of the incident, but it initially complicated diagnosis and represented an ongoing risk of unintended configuration changes. **Mitigations:** * The duplicated configuration was removed from the application pipeline and its state references were cleaned up, making the infrastructure pipeline the single owner of that configuration. * A review is underway to identify any other resources with shared ownership across pipelines. # **Customer Impact** ## **KSAT – New ModStore \(all regions\)** From 13:17 to 13:40 \(UTC\), customers who had the new ModStore experience enabled \(approximately half of customers, plus those who opted in\) received HTTP 500 errors when attempting to access the ModStore and were unable to browse or add training content during that window. All regional instances were affected equally. Customers using the classic ModStore were not affected. All other KSAT functionality — including active training campaigns, phishing simulations, user enrollments, and reporting — operated normally throughout the incident. No customer action was or is required, and no data was lost or altered. # **Preventive Measures** * **Expanded pre-deployment testing —** Test coverage for the new ModStore is being extended to catch the class of defect that caused this incident before a release reaches production. * **Automated error-rate alerting —** Monitoring on the new ModStore is being strengthened so that elevated server-error rates following a deployment automatically notify on-call engineers, removing the dependency on human reports for detection. * **Stronger post-deployment verification —** The automated checks that run immediately after a release are being reviewed so that failures block or escalate a rollout rather than passing silently. * **Single ownership of infrastructure configuration —** Shared infrastructure settings are being consolidated under a single owning pipeline to prevent conflicting automated changes, and an audit is underway to identify any remaining overlaps. # **Conclusion** On May 21, 2026, a defective code change during a routine deployment made the new ModStore experience unavailable for approximately 23 minutes, resulting in server errors for affected customers across all regions. We recognize that the ModStore is central to how administrators build their training programs, and we apologize for the disruption. The response demonstrated the value of fast rollback as a recovery path: the faulty release was identified and reverted within minutes of the first reports, the scope was accurately confirmed early, and no data was lost. The incident also highlighted clear opportunities to improve: stronger pre-deployment testing, automated error-rate detection, and cleaner ownership of infrastructure configuration. These are being addressed through the preventive measures above. We are committed to the reliability of the new ModStore experience as it rolls out to all customers, to ensuring that issues of this kind are caught before they reach production, and to detecting and resolving issues automatically if they do reach production.

Read the full incident report →

Started May 19, 2026, 02:16 PM UTC· resolved May 19, 2026, 06:04 PM UTC

1. identified May 19, 2026, 02:16 PM UTC

   We are seeing errors when using the Microsoft Ribbon Phish Alert Button (PAB) to report emails in Classic Outlook. Our team is aware and investigating these errors.

2. monitoring May 19, 2026, 03:25 PM UTC

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

3. resolved May 19, 2026, 06:04 PM UTC

   This incident has been resolved.

4. postmortem Jun 25, 2026, 06:38 PM UTC

   From Monday, May 18, 2026, at approximately 14:00 \(UTC\), to Tuesday, May 19, 2026, at approximately 15:00 \(UTC\), users experienced timeouts when attempting to use the Microsoft Ribbon Phish Alert Button \(PAB\) in Classic Outlook. This issue was caused by an update to the PAB's authentication process that was incompatible with the Classic Outlook environment. The update used a loading method that Classic Outlook does not support, which caused the PAB to time out before it could connect to KnowBe4's servers. To resolve this issue, we updated how the authentication library is packaged with the PAB to ensure compatibility with Classic Outlook. The Microsoft Ribbon PAB returned to normal performance by approximately 15:00 \(UTC\) on May 19, 2026. To prevent this type of issue in the future, we are updating our processes for compatibility testing and improving monitoring. No data loss occurred as a result of this issue.

Read the full incident report →

Started May 18, 2026, 05:28 PM UTC· resolved May 18, 2026, 09:40 PM UTC

1. monitoring May 18, 2026, 05:28 PM UTC

   Our team has identified an issue causing latency with the KSAT console. A fix has been implemented and we will continue to monitor.

2. resolved May 18, 2026, 09:40 PM UTC

   Our team has identified and resolved the issue causing latency with the KSAT console

Read the full incident report →

Started May 13, 2026, 06:09 PM UTC· resolved May 14, 2026, 01:07 PM UTC

1. investigating May 13, 2026, 06:09 PM UTC

   We are investigating access issues with the KnowBe4 Academy. We will update this page when we have more information.

2. monitoring May 13, 2026, 06:48 PM UTC

   Access to the KnowBe4 Academy has been restored. We are monitoring to ensure there are no further issues.

3. resolved May 14, 2026, 01:07 PM UTC

   This incident has been resolved.

4. postmortem May 14, 2026, 07:07 PM UTC

   On Wednesday, May 13, 2026, from approximately 18:00 until 18:45 \(UTC\), some users experienced issues with accessing the KnowBe4 Academy. This incident was caused by a service disruption with an external service provider. The provider restored service and the Academy returned to normal performance by 18:45 \(UTC\). No data loss occurred as a result of this issue.

Read the full incident report →

Started May 12, 2026, 10:52 AM UTC· resolved May 12, 2026, 03:16 PM UTC

1. identified May 12, 2026, 10:52 AM UTC

   Users will not be able to upload items to US Workspaces, however, downloading is still available. Any Webforms which utilize Workspace will not be able to save items.

2. monitoring May 12, 2026, 11:44 AM UTC

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

3. resolved May 12, 2026, 03:16 PM UTC

   This incident has been resolved.

4. postmortem May 21, 2026, 04:25 PM UTC

   On Tuesday, May 12, 2026, from approximately 10:12 until 11:43 \(UTC\), some US customers experienced issues while attempting to upload files or process data within the Workspace console. This incident was caused by a networking disruption that affected a backend messaging service, preventing it from properly syncing data. While file downloads remained available, new file uploads and certain background tasks were blocked. To resolve this issue, we temporarily paused new network traffic and restored the messaging service. The Workspace console returned to normal performance by 11:43 \(UTC\). To prevent this type of issue in the future, we are reviewing our messaging service configuration and improving network monitoring to more quickly identify synchronization issues. No data loss occurred as a result of this issue.

Read the full incident report →

Started May 08, 2026, 02:05 AM UTC· resolved May 08, 2026, 03:54 AM UTC

1. investigating May 08, 2026, 02:05 AM UTC

   We are investigating an issue impacting the ability to login to PhishER in the US instance.

2. resolved May 08, 2026, 03:54 AM UTC

   This incident has been resolved.

3. postmortem May 15, 2026, 02:44 PM UTC

   On Friday, May 8, 2026, from approximately 01:45 to 03:08 \(UTC\), some US customers experienced issues accessing the PhishER console and PasswordIQ. This incident was caused by a localized infrastructure failure at our cloud service provider, which affected authentication traffic and prevented login verifications. To resolve this issue, we reprovisioned our authentication resources to healthy environments. After we rerouted login traffic to the healthy environments, PhishER and PasswordIQ returned to regular performance by 03:08 \(UTC\). No data loss occurred as a result of this issue.

Read the full incident report →

Started Apr 30, 2026, 01:47 PM UTC· resolved Apr 30, 2026, 04:47 PM UTC

1. investigating Apr 30, 2026, 01:47 PM UTC

   We have identified an issue with customers signing into PhishER in the UK instance.

2. monitoring Apr 30, 2026, 02:13 PM UTC

   We have identified an issue with customers signing into PhishER in the UK instance and implemented a fix which we will continue to monitor. Customers should be able to login successfully.

3. resolved Apr 30, 2026, 04:47 PM UTC

   We have identified an issue with customers signing into PhishER in the UK instance and implemented a fix. Customers should be able to login successfully.

Read the full incident report →

Started Apr 27, 2026, 01:40 PM UTC· resolved Apr 27, 2026, 05:19 PM UTC

1. identified Apr 27, 2026, 01:40 PM UTC

   We have identified an issue with customers pushing ADI files to KSAT. We are actively investigating this issue and will update this page with more information when it is available.

2. identified Apr 27, 2026, 02:42 PM UTC

   We have identified an issue with customers pushing ADI files and training policy uploads to KSAT. We are actively investigating this issue and will update this page with more information when it is available.

3. resolved Apr 27, 2026, 05:19 PM UTC

   We have identified an issue with customers pushing ADI files and training policy uploads to KSAT. Our team has implemented a fix and this has now been resolved.

Read the full incident report →

Started Apr 24, 2026, 08:35 PM UTC· resolved Apr 27, 2026, 11:09 AM UTC

1. monitoring Apr 24, 2026, 08:35 PM UTC

   We are investigating an issue affecting the ability to login to the PhishER platform. Our team is working on this issue and we will update this page when we have more information.

2. resolved Apr 27, 2026, 11:09 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 21, 2026, 08:10 PM UTC· resolved Apr 27, 2026, 11:11 AM UTC

1. investigating Apr 21, 2026, 08:10 PM UTC

   We are investigating reports of latency when viewing or sending emails via Web Access

2. identified Apr 22, 2026, 02:32 PM UTC

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

3. monitoring Apr 23, 2026, 01:05 PM UTC

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

4. resolved Apr 27, 2026, 11:11 AM UTC

   This incident has been resolved.

5. postmortem Sep 16, 2026, 01:45 PM UTC

   From Tuesday, April 21, 2026, at approximately 18:21 \(UTC\), to Thursday, April 23, 2026, at approximately 12:12 \(UTC\), some customers experienced intermittent connectivity and slow performance when using the Protect console in the US region. This issue was caused by unusually high traffic, which led to system unresponsiveness and latency for affected services. To resolve this issue, we performed system restarts, adjusted our resource distribution, and increased our network capacity to accommodate the traffic. Performance for the region stabilized on April 22, and Protect returned to normal performance by approximately 12:12 \(UTC\) on April 23, 2026. To prevent this type of issue in the future, we are implementing new automated alerts to identify high traffic more quickly. We have also permanently increased our network capacity to handle high traffic loads better. Finally, we have improved our system upgrade process to reduce the required time to update. No data loss occurred as a result of this issue.

Read the full incident report →

Started Apr 20, 2026, 03:18 PM UTC· resolved Apr 20, 2026, 06:50 PM UTC

1. monitoring Apr 20, 2026, 03:18 PM UTC

   We've identified the issue that was resulting in a Restricted error when attempting to access the PhishER console for UK and CA customers and have implemented a fix. Impacted users may need to refresh the page to access the PhishER console.

2. identified Apr 20, 2026, 03:53 PM UTC

   We've identified an issue that is resulting in a Restricted error when attempting to access the PhishER console for UK and CA customers, and we are working on implementing a resolution.

3. resolved Apr 20, 2026, 06:50 PM UTC

   We've identified an issue that resulted in a Restricted error when attempting to access the PhishER console for UK and CA customers. Our team has implemented a fix and this has now been resolved.

4. postmortem Jun 30, 2026, 07:32 PM UTC

   On Monday, April 20, 2026, from approximately 14:00 until 20:00 \(UTC\), some customers experienced "Restricted" errors when attempting to access the PhishER console in our UK and Canada instances. This incident was caused by a configuration mismatch during a service deployment. A change in our infrastructure code inadvertently removed a required regional provider alias and upgraded a core distribution module to an unverified version. These combined factors caused regional resources to be resolved incorrectly, which prevented some users from accessing the console. Once we restored the configuration to the correct provider alias and module version, the PhishER console returned to normal performance by 20:00 \(UTC\). To prevent this type of issue in the future, we have implemented stricter rules for software versioning and improved our testing process. We’ve also updated our internal documentation and monitoring alerts to identify and respond to similar configuration errors more quickly. No data loss occurred as a result of this issue.

Read the full incident report →

Started Mar 31, 2026, 03:13 PM UTC· resolved Mar 31, 2026, 04:45 PM UTC

1. identified Mar 31, 2026, 03:13 PM UTC

   We've identified some users are receiving multiple abuse mailbox submissions. We've identified a fix which should resolve the issue.

2. monitoring Mar 31, 2026, 03:19 PM UTC

   We've implemented a fix and are continuing to monitor to ensure this is resolved

3. resolved Mar 31, 2026, 04:45 PM UTC

   This incident has been resolved.

4. postmortem Apr 01, 2026, 09:42 PM UTC

   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.

Read the full incident report →

Started Mar 19, 2026, 12:33 PM UTC· resolved Mar 20, 2026, 12:18 PM UTC

1. investigating Mar 19, 2026, 12:33 PM UTC

   We have received reports that access to the KnowBe4 Administration Panel is slow or inaccessible. We are investigating this issue and will update this page when we have more information.

2. monitoring Mar 19, 2026, 01:48 PM UTC

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

3. resolved Mar 20, 2026, 12:18 PM UTC

   This incident has been resolved.

4. postmortem Mar 26, 2026, 01:42 PM UTC

   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.

Read the full incident report →

Started Mar 18, 2026, 10:33 AM UTC· resolved Mar 18, 2026, 02:28 PM UTC

1. investigating Mar 18, 2026, 10:33 AM UTC

   We are currently experiencing an issue with Webforms not loading and are currently investigating.

2. monitoring Mar 18, 2026, 11:48 AM UTC

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

3. resolved Mar 18, 2026, 02:28 PM UTC

   During a scheduled registrar migration of internal and test domains, a production domain was inadvertently included and not caught in the pre-checks. The initial migration action included updates to the configured Name Servers which resulted in potential service interruptions from 16:00 GMT on March 17 until confirmed full restoration post-propagation at 13:00 GMT on March 18. We have isolated the process issue and remediated. A review of DNS monitoring options is underway to identify opportunities for faster detection.

4. postmortem Mar 24, 2026, 09:04 PM UTC

   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.

Read the full incident report →

Started Mar 10, 2026, 03:48 PM UTC· resolved Mar 10, 2026, 08:32 PM UTC

1. identified Mar 10, 2026, 03:48 PM UTC

   Our development team has identified an issue causing ingested messages in PhishER to display the incorrect sender address.

2. monitoring Mar 10, 2026, 05:02 PM UTC

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

3. resolved Mar 10, 2026, 08:32 PM UTC

   This incident has been resolved.

4. postmortem May 13, 2026, 05:53 PM UTC

   On Tuesday, March 10, 2026, from approximately 15:22 until 20:35 \(UTC\), the EU and US instances of the PhishER console displayed an incorrect subject line for some messages reported with the Phish Alert Button \(PAB\). This incident was caused by a configuration change to the PhishER message ingester service, which unexpectedly affected messages that were reported with some PAB versions. Once we reverted the change and updated the ingester service, PhishER was able to return to normal performance by 20:35 \(UTC\). To prevent this type of issue in the future, we reviewed the ingester service processes and implemented additional testing for messages reported with the PAB. No data loss occurred as a result of this issue.

Read the full incident report →

Started Mar 10, 2026, 12:09 AM UTC· resolved Mar 11, 2026, 10:57 AM UTC

1. investigating Mar 10, 2026, 12:09 AM UTC

   We are currently experiencing an issue with some customers showing an error when trying to submit a form using Webforms. We are aware of the issue and are working on resolving this as quickly as possible.

2. resolved Mar 11, 2026, 10:57 AM UTC

   This incident has been resolved.

3. postmortem May 27, 2026, 09:15 PM UTC

   From Monday, March 9, 2026, at approximately 19:00 \(UTC\) until Tuesday, March 10, 2026, at approximately 17:00 \(UTC\), a subset of Workspace customers experienced Secure Webform submission failures. This incident was caused when a renewed multi-SAN certificate used by our shared authentication infrastructure \(Core ESI\) referenced a newer Certificate Authority \(CA\) root. This update caused dependent infrastructure systems running extended-support operating systems to reject authentication requests due to missing trust anchors, leading to TLS validation failures. To resolve this issue, the required CA root was deployed to the trust stores of the affected systems and service containers, restoring normal authentication behavior. Failed submissions were successfully replayed. Workspace returned to normal performance by approximately 17:00 \(UTC\) on March 10, 2026. To prevent this type of issue in the future, we have reviewed the validation and monitoring processes associated with certificate changes, and we are expanding procedures to include checks from dependent systems and re-architecting systems relying on extended support to ensure required CA roots are available. No data loss occurred as a result of this issue.

Read the full incident report →

Started Mar 05, 2026, 02:36 AM UTC· resolved Mar 05, 2026, 12:44 PM UTC

1. identified Mar 05, 2026, 02:36 AM UTC

   We've identified the cause of the certificate error when navigating to the Defend and Prevent admin consoles and are working on implementing a fix. We'll continue to post on our status page with any new information or updates.

2. monitoring Mar 05, 2026, 03:08 AM UTC

   We’ve implemented a fix for the certificate issue for Defend and Prevent admin consoles. A new certificate has been deployed and most traffic is restored while propagation completes across our global edge network.

3. resolved Mar 05, 2026, 12:44 PM UTC

   This incident has been resolved.

4. postmortem Mar 16, 2026, 03:50 PM UTC

   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.

Read the full incident report →