SLA Credit Claims for IT Providers: A Client Win That Takes an Hour
August 10, 2026
When a client's cloud account has an outage, the provider owes money. AWS, Azure, Google Cloud, and DigitalOcean all publish the breach, then wait for someone to ask for the credit. Your client is not going to ask. You can, in under an hour, because you already hold what every claim requires: the account access, the incident IDs, the logs. The credit lands on the client's next bill, and an outage that could have cost you the account becomes proof you earn your fee. This is the cheapest client win in managed services, and almost no IT provider does it.
Clients never file. You can.
The reasons are boring and predictable. Nobody told the client the credit exists, the invoice never mentions it, and the windows run 30 to 60 days. A client with one account will never learn the rules. An IT provider with thirty accounts learns them once and uses them thirty times. That asymmetry is the whole business, and it is why managed service providers file more claims than anyone else.
The legal layer: who can file for whom
The first question is not "how much" but "who". Each provider restricts who may open a claim, and filing from the wrong side gets the case closed before the evidence matters.
| Provider | Who can file | Channel | Window |
|---|---|---|---|
| AWS | The account holder. Credits cannot be transferred to another account, so the claim is opened from the account that paid the bill | AWS Support Center case | By the end of the second billing cycle after the incident, roughly 60 days |
| Azure | Only CSP direct and indirect providers. Indirect resellers cannot file; their provider files for them | Partner Center support ticket | Azure: 2 months from the end of the billing month. Other services: 1 month |
| Google Cloud | The account holder, or the partner or reseller named in the agreement | SLA contact form linked from each SLA page | Compute Engine: 60 days from eligibility. Most other services: 30 days |
| DigitalOcean | The account holder | Email to success@digitalocean.com | Within two billing cycles of the month the downtime occurred |
Three details change how you operate. AWS does not pay credits under $1, so tiny accounts are not worth the case. AWS also waives automatically any clock hour where a single instance was unavailable for more than six minutes, no claim required, which is the one part of the process that files itself. And distributor deadlines can be tighter than the provider's: Pax8, a large Azure distributor, tells partners to submit by the end of the calendar month after the incident, which is stricter than Microsoft's two months for Azure. Ask your distributor for its internal cutoff before you rely on the provider's.
The credit only exists if someone files inside the window. For your clients, that someone is you. An hour of paperwork turns an outage into money on the client's bill, and the window is the only thing that can kill it.
What you collect while the incident is live
Evidence decays. Logs rotate, timestamps get argued, and the client's memory of the exact start time fades within a week. Collect during the outage, not after:
- The incident ID from the provider's status page or Service Health dashboard. Azure uses a two-letter code plus a number, like EX25194, and Microsoft will not process a claim without it.
- Start and end times in UTC, taken from your own monitoring, not from memory.
- The affected resource IDs: instance IDs, the tenant GUID, project and region.
- Request logs showing errors on the client's own resources, with sensitive data redacted. AWS will not accept a status page screenshot alone.
- For Azure: proof the customer encountered the outage and asked for the credit, sent from an email on the tenant's own domain. Emails from personal addresses are rejected.
The full evidence checklist per provider is here: what counts as evidence in an SLA credit claim.
What a claim is worth
The credit is a percentage of one month's bill for the affected service, not a payout for lost revenue. At $2,000 a month on the affected service, the numbers look like this:
| Provider | Credit tiers | Credit at $2,000/month |
|---|---|---|
| AWS EC2 (region-level) | 10% below 99.99%, 30% below 99.0%, 100% below 95.0% | $200 to $2,000 |
| Azure Virtual Machines | 10% below 99.99%, 25% below 99.0%, 100% below 95.0% | $200 to $2,000 |
| Google Compute Engine | 10% below 99.99%, 25% below 99.0%, 100% below 95.0% | $200 to $2,000 |
| DigitalOcean Droplet | 100% of the affected droplet's charges below 99.99% | Every dollar of that droplet's bill |
The 10% tier is the one you will actually collect, and it pays on small breaches: at a 99.99% commitment, roughly 4 minutes and 23 seconds of downtime in a month is already a breach. The 100% tier is a catastrophic month, which is why the big regional incidents are the ones that pay. DigitalOcean is the outlier worth remembering: any month a single droplet dips below 99.99%, the credit is 100% of that droplet's charges, no sliding scale.
The playbook: from outage to invoice
- While it is down, capture everything in the list above. Screenshot the status page as it happens.
- After it recovers, run the monthly math: did uptime cross below the commitment for the service the client actually runs? The AWS thresholds and deadline walkthrough shows the calculation for the most common case.
- Open the claim with the exact subject line the SLA requires. AWS EC2 spells it out: "Amazon Compute SLA Credit Request - Region-Level Claim". Attach the evidence and put the deadline in the client's calendar the same day.
- On Azure CSP, file one request per customer when fewer than ten customers were hit; a single request listing the impacted tenants works when more than ten were affected. The credit arrives on your next invoice, and you pass it through. That pass-through is the visible part of the win.
- Tell the client. The credit on the bill is the whole story: "Microsoft paid $X after the July outage. We filed it for you." An outage becomes a retention event instead of a churn risk.
The part that requires nothing new
You already run monitoring, you already hold the access, and you already answer the phone during the outage. The claim is the last hour of an incident you are already working. Tools that watch all four providers down to service and region, like UptimeAudit, draft the claim with the deadline attached while the incident is still fresh, but the habit matters more than the tool: capture during, file within the window, show the client the bill.
Do one this week
Take your largest client account on Azure CSP, or your biggest AWS account if you have no CSP exposure. Pull two months of Service Health history and status archives, find every incident that crossed a threshold for a service they actually run, and file the biggest one still inside its window this week: incident ID, tenant GUID, timestamps, request logs, and the client's email from their domain. When the credit lands, show it at the next review. One recovered claim is the entire pitch for this service, because the client can see the result on a bill.