KnowBe4 Status Page

Oct 13, 2026 · resolved Oct 13

## **Summary** On October 13, 2026, from approximately 14:19 to 15:05 \(UTC\), customers in all regions were unable to log in to the KnowBe4 Security Awareness Training \(SAT\) console, the KnowBe4 Learner Experience, and the PhishER console through KnowBe4 SAT. SAML and password logins returned errors, and the KnowBe4 SAT console didn't appear in the KnowBe4 platform. Some background processes, including user synchronization and training emails, also failed during this time. The incident was caused by a production release that conflicted with another change in our code. We reverted the release, and logins recovered across regions between 14:59 and 15:05 \(UTC\). No data loss occurred as a result of this issue. ## **Root Cause** A code deployment removed a startup configuration value to speed up application startup time. A separate component, added to our code after the original change was tested, didn’t account for that changed value. As a result, every attempt to save a user record raised an error, including the update that records sign-in attempts. ## **Customer Impact** Customers across all regions couldn't log in to the KSAT console via SAML or password. They were also unable to access the Learner Experience, and couldn’t access the PhishER console through the KnowBe4 SAT console. New user creation, user synchronization, and training emails failed during this time but were automatically retried after the deployment was reverted. ## **Mitigation and Remediation** We found that the deployment removed a configuration value that another component still required. This was mitigated by reverting the release, and we confirmed recovery across all regions through direct checks and automated tests. We also reverted the original change in our source code and prepared a corrected version that includes a compatibility fix, so the original improvement can be reintroduced safely. ## **Preventative Measures** We're adding additional code verifications and testing for deployments.

Oct 13, 2026 · resolved Oct 13

This incident has been resolved.

Sep 28, 2026 · resolved Oct 2

## **Summary** From Monday, September 28, 2026, at approximately 16:00 \(UTC\), to Wednesday, September 30, 2026, at around 12:35 \(UTC\), some customers experienced delayed mail flow and intermittent problems accessing US instances of Prevent and Protect. On September 28, our monitoring showed heavy network traffic, with spikes at the top of each hour. Some customers began experiencing intermittent problems accessing US instances of the Prevent and Protect consoles. Internal lookups that mail processing depends on started timing out, and messages were queued as a result. Customers reported the issue to our support team, and we posted a status page notice. Performance recovered later that day as US traffic decreased. On September 29, our engineers reviewed the previous day's data across the mail gateways, the internal services they depend on, and the network layer. Mail flow delays and console access issues returned briefly, then eased as network traffic declined, following the same pattern as September 28. On September 30, from approximately 12:19 to 12:35 \(UTC\), our team increased the capacity of the US network services while service continued. Their load dropped immediately after the change, and Prevent and Protect returned to normal performance by around 12:35 \(UTC\) on September 30, 2026. We monitored peak traffic over September 30 and October 1 and saw no recurrences. No data loss occurred as a result of this issue. ## **Root Cause** This issue was caused by a capacity limit in the network services that handle traffic for our US mail-processing services. During peak traffic, and especially during the hourly spikes, the network services couldn't process connections fast enough. This added delay to traffic passing through them and caused some connections to drop. That traffic included internal requests our mail gateways send to look up distribution list members, so the right policies are applied. These requests are subject to a strict time limit so that a slow lookup can't hold up mail processing indefinitely. When the network services delayed requests beyond that limit, they failed. As a result, mail processing slowed, and messages were queued. Two factors made the issue worse and harder to identify. First, some internal requests also used these network services and were affected by the capacity limit. Second, the network services began to degrade before their compute use reached levels that would normally signal a problem. Standard compute monitoring didn't catch the network saturation, so the cause took longer to identify. Finding a safe way to increase capacity without interrupting service also took time, which is why the fix was applied on September 30. ## **Mitigation and Remediation** We found that the US network services didn't have enough capacity to handle peak traffic. We've mitigated this by increasing their capacity in a way that kept service running throughout the change. After the capacity increase, the network services handled peak traffic without further issues. We also found that compute use alone wasn't a reliable sign of network saturation. We've expanded our monitoring to track network health indicators in addition to compute use. Finally, we found it was difficult to find where failing internal requests broke down. We've added logging that shows where internal requests fail and time out. ## **Customer Impact** During peak US traffic on September 28 and 29, some customers experienced delays in processing and delivering inbound and outbound mail through Prevent and Protect. Messages addressed to distribution lists may have been processed more slowly while lookups were retried. Some customers also had intermittent difficulty logging in to or using the US console. The impact eased each day as US traffic decreased, and queued mail was processed once capacity recovered. After the change on September 30, we saw no further degradation during peak traffic. ## **Preventative Measures** To prevent this type of issue in the future, we've increased the capacity of the US network services and expanded our monitoring to track network health indicators in addition to compute use. We've also added logging to improve visibility into failed internal requests.

Sep 24, 2026 · resolved Sep 25

## **Summary** From Thursday, September 24, 2026, at approximately 17:07 \(UTC\), to Friday, September 25, 2026, at around 09:16 \(UTC\), some customers experienced intermittent slowness, errors, and delayed mail flow for US instances of Protect and Prevent. On September 24, an unusually large spike in email traffic placed sustained load on the network services that handle traffic for our US mail processing. Our monitoring alerted us at approximately 17:07 \(UTC\). Some customers saw slow or intermittent access to Protect and occasional errors when loading pages or advanced options. Access was inconsistent, so some customers could use Protect while others saw errors. Mail processing through US instances slowed, and some messages were delayed or didn't appear in the moderation inbox when expected. Performance appeared to improve, so we moved our status page notice to Monitoring at 18:39 \(UTC\). The issue later recurred, and customers reported continued slowness to our support team. At 19:57 \(UTC\), we moved the notice back to Investigating and expanded it to also include Prevent as the impact became clearer. Our team monitored the affected systems while the elevated mail volume subsided. As the load on the network services returned to normal, mail processing recovered, and mail queues returned to normal overnight. We confirmed that Protect was loading normally and that test messages were being delivered again, and then continued monitoring. Protect and Prevent returned to normal performance by around 09:16 \(UTC\) on September 25, 2026. No data loss occurred as a result of this issue. ## **Root Cause** This issue was caused by an unusually large spike in email traffic. The increased volume placed a sustained load on the network services that handle traffic for our US mail processing. Those network services operate within fixed capacity limits, and their capacity couldn't be scaled up during the spike. Because they couldn't keep up with the surge, they slowed down, and some processing failed intermittently. As a result, a large volume of mail was queued in US mail processing, some pages and actions in Protect returned errors, and some messages were delayed or didn't appear in the moderation inbox when expected. Two factors made the issue harder to manage. First, because access failed intermittently, some checks succeeded while customers continued to see errors, making recovery harder to confirm. Second, our monitoring showed peak load on the network services more clearly than the current load, which made it harder to judge in real time whether the load was still elevated. ## **Mitigation and Remediation** We found that the network services handling US mail processing had reached their fixed capacity limits during the traffic spike, and their capacity couldn't be increased during the event. Our team monitored the affected systems while the elevated mail volume subsided and network service load returned to normal. Mail processing then recovered, and queued mail was processed. Because the issue had previously appeared to improve before recurring, we confirmed recovery in several ways before resolving the incident. We confirmed that Protect was loading normally, that test messages were being delivered through US mail processing, and that support requests were progressing normally. We also monitored overnight and received no new reports from customers on US instances. ## **Customer Impact** Some customers had slow or intermittent access to Protect, and occasionally saw errors when loading pages or advanced options. Mail processing through US instances was delayed for Protect and Prevent. In some cases, messages were delayed or didn't appear in the moderation inbox when expected. Customers whose mail is encrypted, decrypted, or moderated as it passes through our US mail processing were more likely to be affected. Most Protect customers using the add-in weren't affected by the mail processing delays. The Protect and Prevent consoles remained available, although some console actions were affected by the slower mail processing. ## **Preventative Measures** To prevent this type of issue in the future, we're improving our monitoring of unusual increases in email volume. We're also improving our monitoring to show the current load on our network services, not only peak values. In addition, we're evaluating ways to scale our network capacity more dynamically during sudden traffic spikes, and assessing longer-term improvements to the network infrastructure that handles US mail processing. We've also since increased the capacity of US network services in response to[ a later incident](https://status.knowbe4.com/incidents/9wc6rjm8g70v).

Sep 23, 2026 · resolved Sep 23

This incident has been successfully resolved and all systems are fully operational.

Is KnowBe4 down right now?

No — KnowBe4 is up. All systems operational as of Oct 18, 2:16 AM UTC.

What is KnowBe4's current status?

KnowBe4: All Systems Operational. Alert24 checks KnowBe4's status page continuously and can notify you the moment it changes.

How do I get alerted when KnowBe4 goes down?

Alert24 monitors KnowBe4 and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.