Updated November 4, 2026 with Microsoft’s final Post Incident Review, which replaces the preliminary review this report first relied on.

An Azure gateway outage between 20:30 UTC on September 30 and 02:15 UTC on October 1, 2026 made management operations fail on several Azure networking services and cut on-premises connectivity for some ExpressRoute customers. Microsoft’s final Post Incident Review (tracking ID 7Q30-010) puts it down to two things at once: a backlog of paused gateway operating system updates resumed all together, and an earlier change had already made each configuration request slower. The shared regional control plane could not keep up with both.

The final review names more services than the preliminary one did:

  • Azure ExpressRoute Gateway
  • Azure VPN Gateway
  • Azure Virtual WAN
  • Azure Firewall
  • Azure Application Gateway
  • Azure Bastion
  • Azure VMware Solution (customers could lose network connectivity to their software-defined datacenter)

Microsoft lists 33 affected regions, spread across the US, Canada, Chile, Europe, the UK, the Middle East, South Africa, India and Asia-Pacific. They include Central US, West US 2, West Europe, North Europe, France Central, Germany West Central, UK South, Southeast Asia, Japan West and Australia Southeast. Impact times varied by region because the trigger was a rolling update moving from one region to the next.

What Microsoft says went wrong

Azure applies operating system and security updates to its networking gateways in stages, so each step can be checked before the next. Before this incident, a temporary deployment restriction had paused those updates for a group of gateways. When the restriction expired, a large number of the held-back updates started within a short period. The result was a surge of gateway restarts, and every restarting gateway asked the regional control plane for its configuration.

At the same time, a change deployed earlier had raised the processing time of each configuration operation in that control plane. More requests, each taking longer, overwhelmed it. Microsoft adds that its existing request throttling and load protection “did not sufficiently protect critical processing under these conditions.”

The preliminary review, published while the incident was still fresh, had described this as a change to a gateway management service that met unrelated maintenance. The final review is more specific: the maintenance was the burst of resumed updates, and the change was a performance regression in the shared control plane.

Most customers saw management operations fail intermittently. ExpressRoute customers could lose the connection itself, for a separate reason. Each gateway has redundant instances, and the update is meant to move to the second instance only once the first is fully back. During the incident, restarted instances were marked healthy before their configuration and routing state had been restored. The update then moved on to the redundant instance, and for some gateways neither instance could fetch the routing configuration it needed.

Those gateways recovered on their own: after about 30 minutes of failed attempts, they fell back to the last known good configuration stored locally. Microsoft’s timeline records that fallback at 22:36 UTC, more than three and a half hours before the incident as a whole was mitigated.

This is the same failure pattern a staged rollout is meant to prevent, and it shows why a health check has to test that the service actually works, not just that the process is running.

Timeline from the final review

All times are UTC, as Microsoft gives them:

  • 20:30, September 30: customer impact begins with intermittent management failures.
  • 20:43: ExpressRoute monitoring detects connectivity degradation.
  • 20:58: control plane monitoring detects health failures in more regions.
  • 21:12: multiple teams are engaged.
  • 21:45: further gateway OS updates are paused.
  • 22:09: traffic shifting brings temporary relief, then load returns; further shifts are stopped.
  • 22:36: affected ExpressRoute gateways restore connectivity from their last known good configuration.
  • 23:55: engineers tie the slower configuration operations to the earlier performance change and decide to roll it back.
  • 01:15, October 1: the rollback starts in one region and is validated there first.
  • 02:15: the rollback is complete across affected regions and customer impact ends.

That is five hours and 45 minutes from first impact to mitigation. Microsoft notes that the times cover the whole incident; actual impact varied by service, region, customer and resource.

What Microsoft is changing

The review lists five repair items with target dates:

  • Roll back the change that caused the performance regression (completed).
  • Make paused OS updates resume in stages instead of across many gateways at once (October 2026).
  • Strengthen ExpressRoute gateway health checks so a redundant instance is updated only after the first has fully restored configuration and routing (March 2027).
  • Fix the platform issues that stopped the control plane from scaling out during the incident (March 2027).
  • Improve throttling and load shedding in the control plane (June 2027).

Microsoft also states that there was nothing customers could have done to avoid or reduce the impact of this specific incident. Its general advice is to set up Azure Service Health alerts and monitoring that shows impact per resource. Microsoft scheduled two Azure Incident Retrospective livestreams on the incident for October 22 and 23, 2026, with recordings to follow on YouTube.

For teams that depend on a single ExpressRoute circuit or VPN tunnel, the incident fits the point of our explainer on why one cloud outage can break unrelated apps: the piece that failed was a shared control plane that customers never configure themselves. If you want to check a provider report like this one line by line, our guide on how to read a post-incident report walks through the sections. Earlier provider reports, with their causes and durations, are collected in our cloud outage tracker.

The same status history page also carries a separate final review for a day earlier: between 10:03 and 15:58 UTC on September 29, Azure OpenAI Service and related Azure AI services in Sweden Central returned intermittent errors after a deployment cleared caches and backend instances fell into a restart loop.