Blog

When the Azure gateway list kept moving

2026-10-08

Microsoft's Azure gateway incident from 20:30 UTC on 30 September 2026 to 02:15 UTC on 1 October started as ExpressRoute in UK South. By the end the public list held five products, a corrected region note, and five regions still changing at 01:36.

At 21:29 UTC on 30 September 2026, Microsoft was investigating Azure ExpressRoute Gateway in UK South. By 02:15 UTC on 1 October the same incident named five products, carried a correction that an earlier region list was wrong, and had already recovered in most regions while five were still taking configuration changes. Paste the 21:29 sentence onto your status page and leave it there, and you tell the wrong story for the rest of the night.

What Microsoft has published

Microsoft's Azure status history keeps this as tracking ID 7Q30-010. Between 20:30 UTC on 30 September and 02:15 UTC on 1 October, a subset of customers using gateway services in multiple regions had degraded or interrupted network connectivity. Customers may have seen gateways fail to load in the Azure Portal, and network management operations fail or lag, on Azure ExpressRoute Gateway, Azure Firewall, Azure Application Gateway and Web Application Firewall, Azure VPN Gateway, and Azure VMware Solution. The page is Azure status history.

The timeline on that summary is the part worth copying into a notebook:

• 20:30 UTC, 30 September: customer impact began.
• 21:29 UTC: investigation of ExpressRoute Gateway in UK South.
• 22:27 UTC: multiple regions, investigation expanded.
• 23:05 UTC: correlation with operating system servicing. Further servicing paused.
• 01:36 UTC, 1 October: recovery across most affected regions. Configuration changes still going into France Central, North Europe, Southeast Asia, UK South, and UK West.
• 02:15 UTC: mitigated.

Microsoft's account of the trigger, in that same summary: a recent change to a regional gateway management service produced a higher-than-expected load when an unrelated operating system servicing maintenance moved through regions. The gateway manager would normally scale. Load on dependent services rose with the extra work, and those regional services did not scale as expected. Microsoft reverted the gateway manager change. Load dropped, and the affected services recovered. They say they are still investigating the scaling behavior. The summary also says the 20:30 to 02:15 window is the full incident duration, not the impact on any one customer or resource.

The summary opens with a correction: impacted regions in a previous communication were wrong. It does not reprint the corrected full region list.

What the page showed while it was still open

The Register, published at 00:54 UTC on 1 October while the incident was open, recorded the region list Microsoft was showing then: West US, West US 3, North Europe, West Europe, France Central, UK West, UK South, Switzerland North, Southeast Asia, East Asia, Japan West, Korea Central, South Africa North, UAE North, Mexico Central, Germany North, South India, and Jio India Central. Azure VMware Solution was not impacted in the last four of those. That is a snapshot of the page at that hour. It is not the corrected list, which the retained summary does not reprint.

The same article quoted Microsoft's 23:13 UTC update. Some affected VPN gateways had reduced redundancy rather than a complete loss of connectivity, and some network management components had not recovered on their own. The Register's 03:30 UTC update, after Microsoft called the incident mitigated, noted that the mitigation notice also named Azure Firewall, Application Gateway, and Web Application Firewall. Those three sit on the retained summary. The product named at 21:29 was ExpressRoute Gateway in UK South.

Four facts that get flattened into one sentence

A gateway incident is not a report that Azure is down. The retained summary is a subset of customers, on gateway services, with three symptoms: connectivity, the gateway blade in the portal, and network management operations. Reduced VPN redundancy, which Microsoft described at 23:13 UTC, is a fourth state. A path is still up, and the spare path is not. UK South was the first region under investigation at 21:29 and was still on the remaining list at 01:36, next to France Central, North Europe, Southeast Asia, and UK West, none of which were in that first sentence. A customer update that freezes any one of those sentences is wrong an hour later.

StackWitness does not publish an Azure truth page. /status has no Azure entry, and a probe of a public hostname would not have shown a gateway failing to load in the portal or a VPN tunnel down to one path. For a dependency whose public host we do measure, that directory keeps the host answer next to the vendor's self-report while their component list is still being rewritten. Reachable means the host answered.

Copy you can adapt

The weak version, which could be pasted onto any incident:

We are aware of a widespread Azure outage across multiple regions. Some customers may experience connectivity issues. We are monitoring and will update when Microsoft marks the incident resolved.

That paragraph costs the night. At 21:40 the only named scope is ExpressRoute in UK South, and support is already telling every customer the product is down. At 01:40 most regions have recovered and five have not, and the paragraph still says widespread and unresolved. Nobody writes down that a VPN lost redundancy rather than connectivity, so the postmortem has the word Azure and no product, no region, and no clock.

Two updates that keep the list dated:

22:40 UTC, 30 September. Microsoft is investigating Azure ExpressRoute Gateway. The 21:29 UTC note named UK South. At 22:27 UTC they widened the investigation to multiple regions. Gateways may fail to load in the Azure Portal, and network management operations may fail or lag. This update covers customers on those gateway services, not every workload in Azure. We will re-read the component list and the region list before the next update.

01:40 UTC, 1 October. At 01:36 UTC Microsoft said recovery had progressed across most affected regions. Configuration changes are still being applied in France Central, North Europe, Southeast Asia, UK South, and UK West. UK South is still on that list. We are not marking this resolved on our side while those five regions are still changing.

A reader who was not on the bridge can check each sentence against tracking ID 7Q30-010 and against your own errors by region and by path. The weak paragraph cannot be checked, so it cannot be trusted an hour later.

What not to do

• Do not publish the 21:29 UK South sentence as the scope at 01:00, or the 00:54 region snapshot as the corrected final list.
• Do not tell every customer Azure is down because ExpressRoute, a firewall, or a VPN gateway is in the impacted set.
• Do not treat reduced VPN redundancy as either fully up or fully down.
• Do not close your customer note when the vendor says most regions have recovered, while five named regions are still taking changes.
• Do not invent a probe of Azure gateways you did not run. A public host answering is not a gateway health check.

Operator checklist

1. Write the time on every sentence you copy from the vendor. The list moves.
2. Name the product (ExpressRoute Gateway, Firewall, Application Gateway, VPN Gateway, Azure VMware Solution), not the cloud.
3. Separate portal load, management operations, connectivity, and reduced redundancy.
4. Re-read the region list before each customer update. Note corrections. Name who is still affected after the majority recovers.
5. Keep Microsoft's full-incident window distinct from the impact on the resource you actually use.

Name the gateway you lost, the region it was in at that minute, and the state it was in. Then read the page again before you send the next update.