What happened
Late on July 18, 2024, the Azure Central US region hit a backend failure in its storage and networking layer. Virtual machines pinned to that region went unreachable, and because so much sits on top of VM compute and Azure Storage, the damage rippled into App Service, SQL Database, and other services that happened to live in Central US. Customers who had concentrated their footprint in one region felt it hardest; teams with cross-region failover rode out most of it.
Timing made this outage unusually confusing. A little over a day later, on July 19, a faulty CrowdStrike Falcon sensor update crashed millions of Windows machines worldwide, including many Azure VMs, and the two events got blended into a single "Azure was down" story in the public mind. They are not the same thing, and for SLA analysis the distinction is everything. The July 18 event was Microsoft's own regional availability failure. The July 19 event was third-party software crashing guest operating systems, which Azure's SLA does not cover.
Microsoft restored the Central US subsystem overnight, and the bulk of affected VMs recovered by early morning UTC on July 19, after roughly seven to eight hours of impact.
SLA credit analysis (the tier and dollar logic)
Azure Virtual Machines are covered by a tiered availability SLA that depends on how you deployed:
- A single-instance VM using premium or ultra storage: 99.9% monthly uptime.
- Two or more instances in the same Availability Set: 99.95%.
- Instances spread across two or more Availability Zones: 99.99%.
The math is unforgiving. A 99.9% target allows only about 43 minutes of downtime in a 30-day month. The Central US outage delivered several hours to affected resources. That puts a single-instance VM comfortably past the 99.9% line and into the credit tiers, which Azure applies against the monthly charges for the affected VM:
- Below 99.9%: a 10% service credit.
- Below 99.0%: a 25% service credit.
- Below 95.0%: a 100% service credit.
Concretely, a team spending 12,000 dollars a month on Central US VMs that landed in the 10% band is owed 1,200 dollars, and one that dropped below 99.0% is owed 3,000 dollars. Note the trap for "redundant" deployments: an Availability Set carries the tougher 99.95% bar, so a shorter outage can still breach it. The credit is scoped to the affected VM charges, and it is never automatic.
There is also a dependent-service layer to consider, exactly as with the AWS cascades. If your App Service plans, SQL databases, or other resources were pinned to Central US and went down because the underlying compute and storage failed, each of those has its own SLA and its own credit schedule. A SQL Database, for instance, publishes its own monthly availability target, so a Central US SQL instance that lost connectivity during the same window is a separate, additional claim priced against your SQL spend, not something folded into the VM credit. The single biggest source of unclaimed money in a regional outage is treating it as one event with one line item, when it is really a stack of per-service breaches that each need their own uptime math and their own case.
How to claim
- Separate the two windows. Document the July 18 Azure regional failure independently from any July 19 CrowdStrike crashes, because only the first is an Azure availability breach.
- Pull your evidence. Use Azure Monitor VM availability metrics and Azure Service Health for Central US, and total the affected connectivity minutes.
- Pick your tier from your computed monthly uptime, remembering the higher bar if you ran an Availability Set or across Zones.
- Price it in the free SLA credit calculator, then submit the claim through the Azure portal support case flow within Azure's claim window.
The Azure SLA credits overview covers the portal steps, and the evidence-gathering guide shows exactly which metrics to attach.
Lessons
- Do not let a nearby, higher-profile event bury a legitimate claim. Many teams wrote off the whole week as "the CrowdStrike thing" and never filed for the real Azure regional breach the day before.
- Redundancy raises your SLA bar, which is good, but it means a redundant deployment can still breach and still owe you a credit. Check the tier that matches your actual topology.
- Region concentration is the recurring theme across providers; the same lesson shows up in the AWS DynamoDB October 2025 post-mortem and the Google Cloud June 2025 post-mortem.
For cross-provider outage tracking see awsdown.com, azuredown.com, and gcpdown.com. Our sponsor Next Signal automates both SLA credit recovery and silent-overcharge detection across your accounts, and cloud-credits.com goes deep on the credit side.