Provider
KnowBe4Incident detail
Workspace degraded performance
Timeline window
to
Outage alerts
Get alerted the next time KnowBe4 breaks
Free email alerts for up to 5 providers — no card, live in about a minute. Paid plans add Slack, Discord, and webhook delivery across your whole stack, plus higher API quotas.
Timeline
Incident updates
Updates are normalized from the official source chronology so timeline changes remain easy to scan.
Investigating
We are seeing intermittent reports of file uploads failing to customers Workspace instances and are currently investigating the issue.
Investigating
We are seeing degraded performance across customer's Workspace instances. Some customers may see additional impact based on their current usage.
Investigating
We have identified this outage is impacting all instances and not just the UK instance as originally reported. We are continuing to investigating this issue and will update this page when we have more information
Resolved
This incident has been resolved.
Resolved
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.