Azure's SLA schedule looks straightforward until you realize the target moves depending on how you deployed the resource. Two customers can suffer the identical outage and one has a valid claim while the other does not, purely because of their architecture. Getting an Azure credit paid means claiming against the right target, inside the two-month window, with Azure's own Service Health record attached. This guide covers the Azure-specific mechanics; for the provider-agnostic overview, start with the complete claim guide, and to see the dollar figure first, use the SLA calculator.
The target depends on your configuration
This is the single most important thing to understand about Azure claims. For Virtual Machines, Microsoft sets three different Monthly Uptime Percentage targets:
| Deployment | Target | What it means |
|---|---|---|
| Across Availability Zones | 99.99% | Highest commitment, requires multi-zone deployment |
| In an Availability Set | 99.95% | Two or more instances in an availability set |
| Single instance, premium storage | 99.9% | One VM using premium SSD |
A 40-minute outage is 99.91% uptime in a 30-day month. That breaches the 99.99% and 99.95% targets, but it sits comfortably inside the 99.9% single-instance target. Before you file, confirm how the affected resource was actually deployed and claim against that specific number. Claiming a 99.99% breach on a resource that only carried a 99.9% commitment gets the whole request rejected.
Convert downtime to Monthly Uptime Percentage
Azure grades on the same monthly-uptime basis every provider uses:
uptime % = (43,200 - downtime minutes) / 43,200 * 100
If you would rather not do the arithmetic by hand, the worked examples in our downtime and uptime guide map minutes straight onto the tier boundaries. Once you have the percentage, compare it against your configuration's target from the table above.
Capture Azure Service Health evidence
Azure reviewers put significant weight on Azure's own incident record, so lead with it:
- The Azure Service Health incident. Export the tracking ID, the impacted services and regions, and the impact window. This is your strongest artifact.
- Azure Monitor graphs. Availability, failed-request, and latency panels covering the incident, with region and time zone visible.
- Resource identifiers. VM names, resource group, subscription ID, and region. Azure evaluates claims per resource.
- A sample of failures. Failed request IDs or error logs that line up with the Service Health window.
Open the claim folder the day the incident resolves. Azure Monitor data can be downsampled after weeks, and Service Health history is not infinite.
Submit within two months
Azure accepts SLA claims for two months from the end of the billing month in which the incident occurred. Enterprise Agreement customers can route the request through their licensing channel; everyone else files a standard Azure support request. Write it like an invoice:
- The SLA by name: the Microsoft SLA for the specific service.
- The month, subscription, and resources: billing month, subscription ID, affected VM names and region.
- The measured uptime, configuration, and tier: "Measured 99.91% on an Availability Zone deployment (99.99% target), in the 10% credit tier."
- The requested credit: "10% of the month's affected Virtual Machine charges: $980."
Verify the credit posts
Approved Azure service credits appear on a subsequent invoice against the affected resource, usually within one to two billing cycles. Confirm the line item actually lands. If Azure rejects on an exclusion (scheduled maintenance, a preview service, customer-side error), request the specific clause and re-check it against your Service Health export; those calls are often reversible with cleaner evidence.
Common reasons Azure claims stall
A handful of avoidable mistakes account for most rejected Azure claims:
- Claiming the wrong target. The single biggest failure. If you claim a 99.99% breach against a resource that was only ever deployed as a single instance (99.9% target), the reviewer rejects the whole request rather than re-grading it. Confirm the deployment first.
- Missing the two-month window. The clock starts at the end of the billing month, not the day you notice. A post-incident review that slips into the next quarter can push you past the deadline.
- Claiming against the whole subscription. Credits apply to the affected resource's charges, not your total Azure spend. Overclaiming triggers slow, skeptical review.
- Preview and free-tier services. Services in preview and free offerings are generally excluded from the SLA. Check the resource was a generally available, paid service before you file.
- No resource-level detail. "West Europe had a problem" is not evidence that your VMs did. Attach VM names, the resource group, the subscription ID, and the region so the reviewer can tie the Service Health incident to your bill.
Azure in the wider claim picture
Azure rarely fails in isolation across a multi-cloud estate. The AWS and Google Cloud guides cover their own windows and targets, which differ significantly. For negotiation angles and credit playbooks, see cloud-credits.com. To confirm the incident timing independently, check the outage archive at clouddowntime.com/data, and set breach alerts at awsdown.com/alerts. New to the process end to end? Walk the how it works flow first.
On a $40,000/month Azure footprint, a single 10% tier is $4,000 for one support request. The two-month window is the only thing standing between you and that credit. Do not let it close.