On 8 October 2026, customers could not reach Gladstone services hosted on our UK South platform. Requests were not routed to our applications for approximately 2 hours. Service was fully restored at approximately 07:50 and remains stable. No customer data was lost or exposed.

Impact

Web traffic to services behind our UK South ingress tier could not be routed. Customers saw errors or timeouts when using:

• All Signature Applications.

The outage lasted from approximately 06:00 to 07:50. During this time no websites were reachable.

Timeline

All times are on 8 October 2026.

Time Event 06:00 Every node in the cluster lost contact with the Azure-managed control plane at the same time, then reconnected. From about 06:05 Supporting cluster services failed to recover. All ingress instances stayed in a not-ready state and could not accept traffic. From 07:15 Our engineers were alerted and began investigating. About 07:40 Engineers confirmed the ingress tier and several core platform components were unhealthy. About 07:45 Engineers restarted the affected platform components. About 07:50 All ingress instances returned to service. Customer traffic resumed. From 08:10 Root cause investigation started. Service stayed stable under monitoring.

Root cause

Our findings point to a fault in the Azure Kubernetes Service (AKS) control plane, which Microsoft manages. It does not appear to have been caused by a change on our side. Microsoft has not yet confirmed the cause, and we will update this summary when they do.

The evidence so far:

• Every node disconnected at once. All of the cluster's nodes lost contact with the control plane within 60 seconds of each other. Separate machines failing together points to the shared control plane, not to any one machine.
• The control plane gave inconsistent answers. After the event, identical requests to the Kubernetes API returned conflicting information about the state of the cluster. Several platform services, including the ingress tier, the metrics service and the network tunnel the control plane uses to reach the nodes, could not reach a healthy, consistent state on their own.
• No change on our side. No deployments, configuration changes or node maintenance took place before the incident. Our node machines stayed healthy throughout, with no CPU, memory or disk pressure.

Resolution

Our engineers restarted the core platform components in the affected cluster at about 07:45. The restarted components reconnected to the control plane and rebuilt their state, and all ingress instances passed their health checks within minutes. Customer traffic has flowed normally since. We have kept the cluster under close monitoring and have made no further changes while the investigation continues.

Next steps

We will confirm the root cause with Microsoft. We have opened a priority support case and will share their findings in an update to this summary once further details have been confirmed.