The July 23 Azure Outage: What It Pays, and the September 21 Claim Deadline
September 16, 2026
On July 23, 2026, Microsoft cut its West US region off from the outside world for 4 hours and 57 minutes. Virtual machines lost connectivity, AKS API servers went unreachable from outside the region, and anything that needed to cross the region's network edge stopped. If that outage hit your workloads, Azure service credits are available but time-boxed: Microsoft must receive your claim within 60 days of the incident, and 60 days from July 23 lands on Monday, September 21.
The 297 minutes, according to Microsoft's own review
Microsoft published a preliminary post incident review under tracking ID ZJV6-SGG. The event started as a break-fix repair on a single optical device, normally processed automatically because it is expected to be impactless. A defect in the blast radius analysis system expanded the repair to include every optical device egressing one datacenter in West US. The safety validation step ran but checked each device individually rather than the aggregate effect of isolating all of them at once, and concluded the work was safe. Routes were withdrawn from every affected device together, severing connectivity between the datacenter and the wide area network.
Two details matter for a claim. Impact was limited to traffic entering or exiting the region, so workloads that stayed entirely inside West US kept working. And the automated rollback failed because it depended on the same connectivity that was down; engineers rolled back by hand at 17:45 UTC, and full recovery came at 19:41 UTC.
| UTC | Milestone |
|---|---|
| 14:44 | Break-fix repair starts on an optical device. Earliest customer impact. |
| 14:45 | Service alerts fire; networking and incident teams start investigating. |
| 15:26 | The routing anomaly is mis-triaged as a WAN issue, aiming the investigation in the wrong direction. |
| 17:19 | Engineers link the route withdrawals to the break-fix and begin rollback attempts. |
| 17:45 | Manual rollback starts. |
| 18:26 | Rollback completes; datacenter to WAN connectivity is restored. |
| 19:41 | All impacted Azure services return to normal. |
The review names what it touched: App Service, Application Gateway, Application Insights, Azure AD B2C, AI Bot Service, AI Search, API Management, Bastion, Cosmos DB, Data Explorer, Database for PostgreSQL, Databricks, ExpressRoute, Firewall, Kubernetes Service, Monitor, Speech in Foundry Tools, Virtual Desktop, Virtual WAN, VMware Solution and VPN Gateway, plus Microsoft Sentinel and Power BI Embedded. Microsoft 365 felt the ripple too, tracked separately as incident MO1437424.
What the affected services promise
Azure credits run on two numbers: the uptime commitment for a specific service, and the monthly uptime percentage you can evidence for your own resources. Commitments on the impacted list sit between 99.9% and 99.99%, and credit schedules run either 10/25/100 or 10/25. From the September 2026 Microsoft consolidated SLA:
| Service (as named in the SLA) | Monthly commitment | Credit tiers |
|---|---|---|
| Virtual Machines, 2+ Availability Zones | 99.99% | 10% / 25% / 100% |
| App Service, Availability Zone enabled apps | 99.99% | 10% / 25% / 100% |
| Database for PostgreSQL, zone-redundant HA | 99.99% | 10% / 25% / 100% |
| Azure Firewall, two or more Availability Zones | 99.99% | 10% / 25% |
| Kubernetes Service, AZ enabled clusters | 99.95% | 10% / 25% / 100% |
| VPN Gateway, non-Basic SKUs | 99.95% | 10% / 25% |
| ExpressRoute circuit, 2+ site configuration | 99.95% | 10% / 25% |
| Application Gateway | 99.95% | 10% / 25% |
| API Management, single region | 99.95% | 10% / 25% |
| Azure Bastion | 99.95% | 10% / 25% |
| Microsoft Sentinel | 99.9% | 10% / 25% |
| Azure Data Explorer | 99.9% | 10% / 25% |
| Power BI Embedded | 99.9% | 10% / 25% |
Each service measures downtime differently, and every definition works at the resource level: Virtual Machines count minutes with no TCP or UDP connectivity to the VM, App Service counts minutes with no connectivity to Microsoft's internet gateway, and Sentinel counts minutes where no HTTP call returned a success code. ExpressRoute adds a condition: on a multi-circuit architecture, credits apply only when both circuits fail at once. The pattern is that the provider measures connectivity to your resource, not whether the region felt broken that day.
The money math for a 4h57m window
The incident lasted 297 minutes. A 30-day month contains 43,200 minutes. A resource that could not be reached for the whole window records 99.31% uptime for the period, which lands in the first tier on every schedule above:
| Commitment | Downtime allowed per 30 days | 297 minutes is | Recorded uptime | Credit tier |
|---|---|---|---|---|
| 99.99% | 4.3 minutes | 69 times over | 99.31% | 10% |
| 99.95% | 21.6 minutes | 14 times over | 99.31% | 10% |
| 99.9% | 43.2 minutes | 7 times over | 99.31% | 10% |
The 25% tier does not open until recorded uptime drops below 99%, which takes more than 7 hours and 12 minutes of cumulative downtime inside the same 30-day window. So for most affected teams this outage is a 10% credit, and the amount depends on what you spent on the service.
A team running $12,000 a month on West US VMs that lost connectivity for the full window is looking at roughly $1,200. A $5,000 Sentinel or Data Explorer bill pays $500. Credits land against future fees rather than as cash, and the base is your spend on that service in the "Applicable Period." For pay as you go metered services, Microsoft defines that as the 30 days ending on the incident date, July 23, not the calendar month. That fine print cuts both ways: a spend spike just before the incident inflates the credit, and a quiet month shrinks it.
One caution: the credit attaches to evidence about your resources, not to the regional incident window. The review itself says "actual impact to service availability varied between customers and resources." If your workloads were only partially degraded, or your monitoring ran from inside the region, your recorded downtime may be small or zero.
The whole game is the deadline. Microsoft says it must receive the claim within 60 days of the incident, and the same clause says missing information gets claims rejected outright. For the July 23 outage, the 60th day is Monday, September 21.
How to file before the window closes
Azure claims go through the portal: Help + support, New support request, issue type Billing, problem type Refund Request. The SLA requires five things, and it is blunt about missing pieces:
- A detailed description of the incident.
- The time and duration of downtime.
- Affected resource names.
- The number and location of affected users.
- A description of the errors that occurred.
Cite tracking ID ZJV6-SGG so support can match your request to the public review, and attach your own timestamps and error logs. If more than one service was affected, file one claim per service: Microsoft's terms say you can submit claims as if each service were covered by its own SLA. Processing typically takes up to 45 days from receipt, and the approved amount is applied to future fees.
Related reading: the step-by-step Azure refund process and what counts as evidence in a claim.
One more track: the Microsoft 365 cascade behind Teams and Outlook runs on different terms, with claims due by the end of the month after the incident. For July, that was August 31, so that route has closed. The Azure window is the one still open.
One action for today
If West US resources of yours lost connectivity on July 23, open one Billing support request per affected service and subscription, cite tracking ID ZJV6-SGG, attach your timestamps and error logs, and send it in before Monday, September 21. The outage happened 55 days ago; the claim takes an afternoon, and Monday is the last day it can reach Microsoft's claims team.