Is Siteimprove down?

Executive Summary: On July 16, 2026, some users on our EU and US platforms were unable to log in for approximately two hours. The issue was caused by an outage at a third-party authentication provider, which was itself triggered by a major operational issue at a large cloud infrastructure provider. The provider restored service by rerouting their traffic, and our platform recovered automatically. There was no data loss and no action required on our side. Incident Overview: The initial step of our password and single sign-on (SSO) login journeys is handled by a third-party authentication provider. When that provider became unreachable due to an upstream cloud infrastructure issue, users attempting those login journeys received authentication errors. Because the failure sat entirely within an external dependency, there was no component on our side to repair. The provider mitigated the issue by rerouting their traffic away from the affected infrastructure, after which our login journeys recovered on their own. Impact: Password-based and SSO logins on the EU and US platforms were mostly unavailable from approximately 2026-07-16T07:55Z to 2026-07-16T09:55Z. Users signing in through direct links were unaffected throughout, and users already logged in were able to continue working. Detection: The incident was detected at 2026-07-16T07:55Z by our automated monitoring, which flagged the authentication provider as unreachable and shortly after picked up failing login checks across both EU and US. Response: Our operations team began investigating and confirmed the failure was an outage at the third-party authentication provider, which had already published a status update acknowledging the issue. We contacted the provider directly and confirmed there was no corrective action available on our side, as the fault was entirely within their infrastructure. Root Cause: A major operational issue at a large cloud infrastructure provider disrupted the routing our third-party authentication provider depends on, making it unreachable. Because that provider handles the first step of our password and SSO login journeys, those journeys failed while the outage lasted. Next Steps While this incident originated entirely outside our systems, we are reviewing options to reduce the impact of any future third-party authentication outage, including improved alerting granularity around upstream provider health and fallback options for the login path. We are also following up with the provider on their own remediation steps.

We are currently experiencing issues where some customers are unable to log in to the Siteimprove platform using SSO via siteimprove.com and my2.siteimprove.com. Impact: - Users who are already logged in should not experience disruption unless they log out or their session times out. - New login attempts may fail. Our Development Team is actively working to identify the root cause and resolve the issue as quickly as possible. We apologize for this inconvenience. We'll continue to keep you updated.

Good news! We’ve found the issue and we’re working on a fix. Thanks for your patience! We'll continue to keep you updated.

A fix has been implemented and we are monitoring the results. SSO Users should now be able to successfully log into the Siteimprove platform via siteimprove.com and my2.siteimprove.com disruption free.

The issue affecting SSO logins to the Siteimprove platform is all sorted. We’re sorry for holding you up! If you have any additional questions or feedback, please submit a new support ticket through our Help Center ("?" button) located at the top right-hand-side of the Siteimprove platform.

**Executive Summary:** On May 6, 2026, an infrastructure failure in our Kubernetes environment caused SSO login failures for a subset of users for approximately 42 minutes. All other platform functionality was unaffected. The issue was caused by a loss of quorum in an internal cluster's control plane, compounded by a node that had been silently degraded. The incident was resolved by replacing the affected nodes, and the system has been operating normally since. **Incident Overview:** The issue originated from an internal infrastructure cluster that acts as a connectivity bridge between our environments. Two of the cluster's three control plane nodes became non-functional — one had been in a degraded state, and a second failed during normal operations. With two of three nodes down, the cluster could no longer coordinate its workloads, which disrupted the network path required for SSO logins for some users. Some of our internal tooling was also affected. To resolve the issue, the team replaced the unresponsive nodes, which restored normal operations. Login functionality recovered shortly after. **Impact:** Some users logging into the platform via SSO experienced failures from approximately **2026-05-06T14:34Z** to **2026-05-06T15:16Z** \(~42 minutes\). **Detection:** The incident was detected at **2026-05-06T14:34Z** when our automated monitoring system identified connectivity failures in the login journey, which alerted the operations team. **Response:** Our operations team began investigating immediately. The affected control plane nodes were identified and replaced, with full recovery confirmed via automated tests at **2026-05-06T15:16Z**. A status page update was posted during the incident. **Root Cause:** Two of three control plane nodes in an internal cluster became unavailable at the same time — one had been silently degraded, and a second failed independently. The monitoring pipeline that should have detected the degraded node ahead of time was itself not functioning correctly. Because it only logged on failure and not on success, its silence was indistinguishable from normal operation, and the team had no way to know it had stopped working. Follow-up actions updated the monitoring pipeline to emit success signals so that their absence can be alerted on, improving overall control plane monitoring coverage, and introducing scheduled control plane node replacements as a preventive measure.