Azure SLA Credits: Service Health, Refund Requests, and the Two-Month Deadline
August 6, 2026
Azure will refund you when it misses its own uptime targets, but only if you file a refund request before a two month window closes. On July 23, 2026, a bug in Azure's maintenance automation removed IP routes from more devices than intended and blocked traffic in and out of West US for 4 hours and 57 minutes. For workloads that crossed the region boundary, that is 297 minutes of downtime against a 30 day applicable period of 43,200 minutes, about 99.31% uptime. That breaches every VM and App Service tier in this article, and the credit starts at 10% of the affected service fees. Microsoft did not email anyone to say so. This walkthrough covers how to read Service Health, which thresholds matter, and how to file before the deadline passes.
Service Health is the only view that knows your account
Azure publishes two different health surfaces, and confusing them is the first mistake. The public status page at azure.status.microsoft shows only widespread issues that meet Microsoft's publication criteria. It does not know your subscriptions, your regions, or your resource groups, and it gets edited after the fact.
Service Health inside the portal is the per-account view. It tracks issues affecting the subscriptions you can see, and its Health history tab keeps the incident list with tracking IDs. The July 23 West US event is recorded there as "Issues connecting to resources in West US" with tracking ID ZJV6-SGG. When you file a claim, that tracking ID is the reference Microsoft expects you to cite.
Set up Service Health alerts now, not after the next outage. An Azure Monitor action group can push incident status updates to email or into your own incident management system as Microsoft updates them. During an active incident you can also open a free support ticket within 72 hours of mitigation for recovery help. That is separate from the credit claim, but it is how you get Microsoft's engineers to confirm what happened to your specific resources.
The thresholds that trigger a credit
Azure publishes per-service SLAs in the consolidated online services document, updated monthly. The numbers below come from the July 2026 edition. Uptime is measured per subscription over the applicable period, and a credit applies only to fees for the affected service, not your whole invoice.
| Deployment | Commitment | 10% credit | 25% credit | 100% credit |
|---|---|---|---|---|
| Virtual Machines across 2+ Availability Zones | 99.99% | below 99.99% | below 99% | below 95% |
| VMs in an Availability Set or Dedicated Host Group | 99.95% | below 99.95% | below 99% | below 95% |
| Single-instance VMs (Premium SSD) | 99.9% | below 99.9% | below 99% | below 95% |
| App Service with Availability Zones | 99.99% | below 99.99% | below 99% | below 95% |
| App Service without Availability Zones | 99.95% | below 99.95% | below 99% | below 95% |
| SQL Database, zone redundant | 99.995% | below 99.995% | below 99% | below 95% |
| SQL Database, single region | 99.99% | below 99.99% | below 99% | below 95% |
| Cosmos DB, multiple write regions | 99.999% | below 99.999% | below 99% | below 95% |
The top tier is the one to watch. A 99.99% commitment allows about 4.3 minutes of downtime in a 30 day period, so a single bad hour almost always crosses into credit territory. The 4 hour 57 minute West US outage clears every threshold in this table for affected workloads.
Two details change the math for some deployments. Single-instance VMs drop to a 99.5% commitment on Standard SSD disks and 95% on Standard HDD, so check your disk tier before assuming the 99.9% number applies. And for metered pay-as-you-go services such as virtual machines, the applicable period is not the calendar month. It is the 30 days ending on the first day of the incident. That can shift your monthly uptime number by a fraction of a percent, which matters when you sit just above or below a tier boundary.
The deadline: two months from the end of the billing month
Microsoft requires Azure SLA credit requests to be submitted within two months of the end of the billing month in which the incident occurred. For the July 23 incident the billing month ends July 31, so the claim window closes September 30. Other Microsoft online services get only one month. Azure's two months is the generous one, and it is still short.
This deadline is where most recoverable money dies. An outage is loud, so people notice it the day it happens. Two months later, with a different sprint and a newer incident on the calendar, nobody files. If you were affected in West US in July, put September 30 in your calendar today.
The one sentence to keep: an outage is loud, but the claim window is quiet. Nobody at Microsoft will remind you that September 30 exists, so the deadline goes in your calendar the same day the incident ends.
Filing the refund request
Microsoft's own incident response guidance states the path plainly: create a new support request with a problem type of Refund Request and include the incident tracking ID. The steps:
- Open the Azure portal and go to Help + support, then New support request.
- Set issue type to Billing and problem type to Refund Request.
- State in the description that this is an SLA credit request, and name the service and region.
- Include the tracking ID from Service Health, your subscription ID, and your tenant GUID.
- Give the outage window in UTC, plus evidence the outage hit your resources: error logs, failed request counts, screenshots with timestamps.
- Submit and watch the case. Approved credits appear on the next invoice.
Microsoft's partner documentation lists what a claim needs to survive review: the customer tenant GUID, the outage incident ID from Service Health, proof the outage affected you, and a request submitted from an email address on the affected tenant's domain. Personal email addresses are rejected outright. Screenshot the Service Health entry and the status history page while they are live, because both get edited as incidents are resolved.
Advisory incidents usually do not qualify. Microsoft notes that an incident post on the health dashboard only means a tenant might be affected, and the final incident post and post incident review are the records that count. A claim built on your own request logs beats one built on a status page screenshot every time.
What a credit actually looks like
Credits are prorated by affected service and outage duration, applied to a future invoice, and capped at the monthly fee for the affected resource. They are not cash and they do not transfer. A 10% credit on $5,000 of West US VM spend means $500 off a later bill, not a check.
The exclusions are real. Scheduled maintenance does not count as downtime, customer side faults are excluded, and outages outside Microsoft's control are excluded. App Service credits cover only Web, API, Mobile, and Logic app fees, not the other app types in that service. Read the service specific terms for the exact list before you file.
One situation changes everything: if you bought Azure through a Cloud Solution Provider, you do not file in the portal at all. The partner files the claim in Partner Center, and they need the same incident ID and proof from you. The two month window still applies, so chase your partner.
The one action that matters
Open the Azure portal, go to Service Health, open Health history, and check for incidents in the last two months that touched your subscriptions. If you find one, start the refund request in the same session. For everyone who ran workloads in West US on July 23, that window closes at the end of September. The same process, thresholds, and evidence rules are summarized in our four provider claim guide if you run workloads elsewhere too.