Service has been operating normally since recovery on 21 July. We are sorry for the disruption and we appreciate your patience while we completed our investigation.

We have confirmed the cause. OMS reached a limit on the number of outbound network connections available when communicating with a supporting service. Once that limit was reached, requests to the supporting service slowed down, which increased pressure on part of the OMS hosting environment and caused additional requests to slow down or fail. We restored service at the time by moving OMS to fresh hosting capacity.

No impact to client data integrity has been identified. Client-operated scanning and integrations continued independently, and we received no related scanner-downtime or synchronisation reports during the incident.

Hosting Resilience

We have implemented a dedicated, more reliable outbound connection path in staging, removing the limit that caused the disruption. This is going live in production with release 1129.

Before and after. OMS moves from a shared route to one reserved for it alone.

Automatic Recovery And Alerting

OMS already benefits from automatic recovery by default, and we have added alerting so our team is notified immediately whenever OMS restarts, whether planned or unplanned.

Session Continuity

We are adding the ability for your active session to remain intact if OMS restarts, so you will not need to sign in again. This is targeted for release 1130.

Before and after. Your session is held separately, so a restart no longer signs you out.

The hosting-resilience fix that addresses the underlying cause is planned for production in release 1129, targeted for 20 August 2026. Session continuity is targeted for release 1130, expected around September 2026. Until the release 1129 fix is live, a recurrence remains possible, although we expect it to be rare.

Release 1129 has now been published in our regular release notes. Session continuity will be covered the same way in our regular release notes ahead of release 1130, rather than through a separate deployment confirmation here. We will close this incident once release 1130 has been deployed.