Every SLA claim rests on one number: your service's monthly uptime percentage. Get the conversion right and the credit tier falls out of a table. Get it wrong, count the whole account instead of the affected service, or use the wrong number of days in the month, and the claim gets rejected or under-filed. This guide is the arithmetic, done carefully, with worked examples for all three major providers. To skip straight to a dollar figure, the SLA calculator does the whole conversion for you; this guide is for understanding what it computes.
The core formula
Uptime is the share of the billing month your resources were available:
uptime % = (total minutes in month - downtime minutes) / total minutes in month * 100
The one detail people get wrong is "total minutes in month." It is not always 43,200. Use the real calendar:
| Month length | Total minutes |
|---|---|
| 28 days (February) | 40,320 |
| 30 days | 43,200 |
| 31 days | 44,640 |
Providers grade on the actual billing month, so a 40-minute outage produces a slightly different percentage in February than in March. When you are near a tier boundary, that difference can decide the claim.
What each uptime target actually allows
Flip the formula around and each target becomes a downtime budget. For a 30-day month:
| Target | Allowed downtime (30-day month) |
|---|---|
| 99.9% | about 43 minutes |
| 99.95% | about 21 minutes |
| 99.99% | about 4.3 minutes |
| 99.999% | about 26 seconds |
This table is why the exact target matters so much. The gap between 99.9% and 99.99% is not a rounding difference; it is the difference between a 43-minute budget and a 4-minute one. An outage that is a clear breach against a 99.99% commitment can be entirely inside a 99.9% one.
Worked example 1: AWS EC2
Suppose EC2 in us-east-1 was unavailable for 90 minutes in a 30-day month.
uptime % = (43,200 - 90) / 43,200 * 100 = 99.79%
The Amazon Compute SLA target for a multi-AZ deployment is 99.99%. 99.79% is below 99.99% and at or above 99.0%, which lands in the 10% credit tier. On $50,000 of affected EC2 spend that month, the credit is $5,000. Full filing detail is in the AWS SLA credit guide.
Worked example 2: Azure VM configuration
Now a 40-minute Azure Virtual Machine outage in a 30-day month:
uptime % = (43,200 - 40) / 43,200 * 100 = 99.91%
Here the configuration decides everything. Against a 99.99% Availability Zone target, 99.91% is a breach (10% tier). Against a 99.9% single-instance target, 99.91% is inside the SLA and there is no claim. Same outage, opposite outcome. The Azure SLA credit guide walks the per-configuration targets in full.
Worked example 3: Google Cloud, tight window
A 30-minute Compute Engine outage in a 30-day month:
uptime % = (43,200 - 30) / 43,200 * 100 = 99.93%
Against a 99.99% multi-zone target, that is a breach in the first Financial Credit tier. The catch with Google Cloud is not the math, it is the 30-day notification window, covered in the Google Cloud SLA credit guide. Do the conversion the day the incident resolves so you have time to file.
Turning a tier into money
The last step is the one that decides how big the check is, and the most common place people underclaim. Multiply the tier percentage by the affected service charges for that billing month, not your entire cloud bill:
credit = tier % * (affected service charges for the month)
A 10% tier on $30,000 of affected EC2 spend is $3,000, even if your total AWS bill was $200,000. Claiming against the whole bill triggers a slow, skeptical review and usually a rejection. Claim precisely, and the number is defensible.
Common mistakes to avoid
- Using 43,200 every month. February and 31-day months change the percentage near a tier boundary.
- Counting slowness as downtime. Most SLAs measure unavailability or an error rate above a threshold, not latency.
- Ignoring configuration. The target changes with your architecture; the Azure example above shows how the same outage can flip from claimable to not.
- Claiming against the whole bill. Tiers apply to the affected service's charges only.
Where to go next
Once you have the percentage and tier, move to the provider-specific filing steps in the AWS, Azure, and Google Cloud guides, or the cross-provider complete claim guide. For credit playbooks and negotiation tactics, see cloud-credits.com. To confirm outage timing independently, use the archive at clouddowntime.com/data and set breach alerts at awsdown.com/alerts. New to the process? Start with how it works, then run your numbers through the calculator.
The conversion is grade-school arithmetic, but it is the foundation every claim stands on. Do it carefully, count the right minutes and the right service, and the credit tier stops being a mystery and becomes a line item you are owed.