On 16 July 2026, between approximately 07:50 and 11:20 UTC, the Equiem web platform, operational tools and Equiem One were unavailable or failing intermittently for all customers. Users saw pages timing out or returning 504 errors. The cause was a global outage of Amazon Web Services' CloudFront network, which Equiem uses to deliver these services. This was an upstream AWS event affecting many services across the internet and was not caused by any change on Equiem's side. The mobile app remained operational throughout, with the exception of embedded modules such as visitor management, bookings and request management.
At 07:53 UTC our automated monitoring detected the first failures, and within minutes users were unable to load the web platform across all sites. We declared a critical incident, opened an incident on this status page at 08:18 UTC, and notified all registered incident contacts directly by email at 08:28 UTC.
By 08:46 UTC we had confirmed the root cause as a global AWS CloudFront outage, specifically affecting the connectivity type Equiem uses to route traffic securely to our infrastructure. Because the failure sat entirely within AWS's network, resolution depended on AWS. In parallel, our engineering team began preparing a workaround that would have rerouted traffic away from the affected AWS component, in case the outage became prolonged.
AWS began rolling out a fix at approximately 11:10 UTC. We verified the web platform, operational tools and Equiem One were operational across all sites by 11:43 UTC and moved the incident to monitoring. AWS confirmed full resolution shortly afterwards, and we marked the incident resolved at 13:19 UTC.
Web traffic dropped by approximately 80% during the 3.5 hour window, with most new page loads and sign-ins failing. The platform was not fully down: users who already had a session open could often continue browsing, and the mobile app was unaffected apart from embedded modules such as visitor management, bookings and request management.
While the root cause was external, our responsibility is to be resilient to it. We are investigating whether the connectivity configuration affected in this outage remains the right trade-off between security and resilience, what our fastest response path would be in any future CDN outage, and the cost and practicality of redundancy across our key infrastructure. These reviews are underway with our engineering team and will inform concrete changes.