Workspace degraded performance

Update timeline

1. investigating Feb 10, 2026, 12:25 PM UTC

   We are seeing intermittent reports of file uploads failing to customers Workspace instances and are currently investigating the issue.

2. investigating Feb 10, 2026, 12:57 PM UTC

   We are seeing degraded performance across customer's Workspace instances. Some customers may see additional impact based on their current usage.

3. investigating Feb 10, 2026, 01:27 PM UTC

   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

4. resolved Feb 11, 2026, 02:08 PM UTC

   This incident has been resolved.

5. postmortem Feb 25, 2026, 03:38 PM UTC

   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.