Azure Outage: When the Road to the Cloud Breaks

From 03:30 to 09:15 WIB on 1 October 2026, Azure's gateway services, the connection points that link office and factory networks to Microsoft's cloud, failed in 18 regions, Southeast Asia included. Some workloads could keep running while their gateway paths were unavailable. The reports do not establish the health of every affected server. A cloud plan needs a plan for the road, not only the destination.

This article walks through what Microsoft has said so far, why a maintenance job could cause it, and what to check if your branches, hotels or plants depend on a tunnel into Azure.

What happened on 30 September and 1 October?

Microsoft's Azure status history (tracking ID 7Q30-010) puts the impact between 20:30 UTC on 30 September and 02:15 UTC on 1 October 2026. That is 5 hours and 45 minutes, starting at 03:30 WIB and ending at 09:15 WIB, well into the Indonesian morning.

The affected services were all of the "road" kind:

• VPN Gateway: the encrypted tunnel over the ordinary internet that joins an office network to a private network in Azure.
• ExpressRoute Gateway: the Azure end of a private leased line, the option companies pay extra for precisely because it is supposed to be more reliable.
• Azure Firewall, Application Gateway and Web Application Firewall: the checkpoints that filter and route traffic before it reaches your servers.
• Azure VMware Solution, which leans on the same network plumbing.

The list of 18 regions included Southeast Asia (Singapore), East Asia (Hong Kong), Japan West and Korea Central, alongside most of Europe and parts of the US, India, the Middle East and Africa. The Register's report noted that some VPN gateways lost only their redundancy, the standby half of the pair, rather than going fully dark, and that Microsoft had to restore some network management components by hand using alternate instances.

Why did a maintenance job break the connections?

Microsoft's preliminary explanation has two parts. A recent change to the regional service that manages gateways made it generate more load than expected. At the same time, a routine operating-system update was rolling gradually through the regions. Normally the management service would autoscale, adding capacity on its own as demand grows. This time the services it depends on were overloaded too, so it could not grow fast enough.

Think of road repairs done one lane at a time, a normal thing. Then the traffic control office, the one that tells every repair crew which lane to close, gets flooded with calls and stops answering. The roads were never the problem. The office that runs them was.

Microsoft paused the update at 23:05 UTC, two and a half hours into the incident, and says full post-incident reviews are generally available within about 14 days. Check availability through Azure Service Health.

The day before, a separate incident (tracking ID 7QL5-Z50) hit Azure OpenAI and the Foundry AI services in Sweden Central for almost six hours, from 10:03 to 15:58 UTC on 29 September. The cause there was also internal: a background process flooded a metadata database with requests until the service kept restarting. These incidents had different causes, but both originated in the provider’s internal processes. The earlier incident report does not identify maintenance as its trigger.

You cannot schedule around maintenance you never see. You can only design for it.

Why does this hit Indonesian operations harder than it looks?

Look at the clock. 03:30 to 09:15 WIB covers the night shift handover, early hotel checkouts, factories starting the morning shift and retail branches opening their tills. A dashboard team in Europe might sleep through an outage like this. An operator in Jakarta or Surabaya walks straight into it.

Then look at the region. Microsoft opened Indonesia Central, its first region here with three availability zones in the Jakarta area, in May 2025. Plenty of Indonesian companies moved to Azure before that and still run in Southeast Asia, which was on the affected list. Indonesia Central was not on this list. Its absence from the affected list does not establish why it was unaffected or guarantee future isolation.

Availability zones alone may not protect against a shared gateway-management failure. Zones protect you from one data centre losing power or cooling. This failure sat in a regional management layer that serves all zones at once. We made the same point about the AWS us-west-2 outage: spreading servers across zones does not remove dependence on shared regional components.

The setups that suffer most are hybrid ones, where part of the system lives on site and part in the cloud, joined by a tunnel:

• Retail branches whose POS terminals post every sale to an ERP in Azure.
• Hotels with an on-premise PMS (property management system) syncing to a cloud database or reporting stack.
• Factories where the line terminals look up work orders in a cloud MES (manufacturing execution system).
• Offices where staff log in against a domain controller that lives in Azure.

These examples illustrate how a failed path can interrupt work even when both endpoints remain healthy; they are not verified outcomes for each affected company.

Which of your systems depend on that road?

Most teams cannot answer this in five minutes, and that is the first finding. Make a list of every flow that crosses the tunnel, with four columns:

The last column is the one that matters. A flow where the answer is "the site stops working" is a single point of failure, one part whose failure takes everything with it. We covered how to find these in single points of failure in business systems.

What should the backup path look like?

The usual answer is "ExpressRoute primary, VPN backup". In this incident both gateway types were affected in the same regions, so that pair could have gone down together. A backup path only counts if it does not share the part that failed.

Three options to assess against the cost of interruption:

1. Let the site work alone for a while. The branch keeps selling, the hotel keeps checking guests out, the line keeps running, and transactions wait in a local queue until the tunnel returns. This is the most reliable option because it does not need any road at all. The design details are in our piece on offline-first field apps.
2. A second road through different parts. For the few flows that cannot wait, publish them through a separate path: an HTTPS endpoint with proper authentication, a tunnel to a second region, or a route through another provider. The test is simple. Ask which component failed on 1 October and check that your backup does not use it. Application Gateway was on that list too, so an emergency endpoint behind it in the same region is not a separate road.
3. A written switch-over procedure. Who decides to switch, what they change, and how they switch back. A backup path that only one engineer knows how to turn on is a backup path that will be turned on late.

Option 1 may cover flows that can tolerate delayed synchronisation. Options 2 and 3 are for flows where six hours of waiting costs more than building them.

How do you know it is the road and not your server?

Microsoft's own timeline tells the story: impact began at 20:30 UTC, the investigation started at 21:29 UTC, and the multi-region scope was only identified at 22:27 UTC. For the first hour, an IT team looking at a dead tunnel had nothing official to go on. That hour usually goes to rebooting your own servers and calling the local ISP.

Watch the road from your side:

• Probe across the tunnel. A small script at each site that requests a private address in Azure every minute and alerts after three failures. If the site's internet is fine and the probe fails, investigate the tunnel, routing, firewall, and destination service. A failed probe does not by itself isolate the fault.
• Subscribe to Azure Service Health alerts for your regions and the gateway services you use, so the provider's notice reaches your phone rather than a portal nobody has open at 04:00.
• Log the tunnel state next to your application logs, so the post-incident report can line up "sales stopped syncing" with "tunnel went down" in minutes.

Our guide to monitoring and alerting for small systems covers the basics of the alert side.

What should you check this week?

• List the flows that cross your VPN or ExpressRoute gateway, with the "if it stops for 6 hours" column filled in.
• Check whether your gateways sit in one of the 18 affected regions, and whether anything at your sites actually failed between 03:30 and 09:15 WIB on 1 October.
• For each flow that stops a site, decide: local queue, second road, or accept the risk in writing.
• Set up one cross-tunnel probe and one Service Health alert.
• Check Azure Service Health and read Microsoft’s post-incident review when available, and check whether the "next steps" touch the gateways you use.

Cloud providers will keep doing maintenance, and some of it will go wrong. The servers you rent are only as useful as the road your people take to reach them.