Skip to main content

Cloud SLA Credits: Fundamentals & Eligibility

Everything you need to know about cloud SLA credits, downtime eligibility, and how to claim refunds for AWS, Azure, and GCP.

Cloud SLA Credits: The Fundamentals

What is a cloud SLA credit, and am I entitled to one? A cloud SLA (Service Level Agreement) credit is a financial compensation issued by a cloud provider when the provider fails to meet its contractually guaranteed uptime or availability thresholds. If your cloud services experience downtime that breaches the SLA, you are legally entitled to a service credit. Entitlement is not automatic: you must file a claim within your provider's specified window, provide documentation of the disruption, and meet configuration eligibility requirements.

What is the difference between an SLA credit and a cash refund? Cloud SLA credits are not cash refunds. They are account credits applied toward your future cloud service invoices with that provider. AWS, Azure, GCP, Microsoft 365, and GitHub all operate this way: credits offset upcoming charges but are not disbursed as money. This distinction matters for FinOps accounting: SLA credits reduce future cloud spend rather than generating revenue.

How much downtime is required before I qualify for an SLA credit? Eligibility thresholds vary by provider and service tier. As a reference: AWS EC2 (Multi-AZ) guarantees 99.99% monthly uptime; any breach triggers a credit. Microsoft 365 Business Premium guarantees 99.9% uptime (approximately 43 minutes of tolerated downtime per month). GitHub Enterprise Cloud guarantees 99.9% quarterly uptime. GCP Compute Engine guarantees 99.95%. Azure VMs in Availability Zones guarantee 99.99%.

Do cloud providers automatically issue SLA credits when there is an outage? No. None of the major cloud providers, including AWS, Azure, Google Cloud, Microsoft 365, and GitHub, automatically issue SLA credits. You must proactively identify the outage, measure its impact, document the downtime with supporting log data, and submit a formal credit request within the provider's claim window.

What is the deadline to submit an SLA credit claim? Claim deadlines vary significantly by provider. AWS requires claims by the end of the second billing cycle following the incident. Azure allows two months from the incident date. GCP allows 60 days from eligibility for Compute Engine and 30 days for Cloud Run. Microsoft 365 and GitHub Enterprise both require claims within 30 days of the end of the applicable period. Missing these deadlines results in permanent forfeiture of the credit.

What documentation do I need to file a cloud SLA credit claim? Most providers require: (1) dates and times of the disruption; (2) application or service logs demonstrating the service was unavailable; (3) confirmation that the disruption was caused by the provider; and (4) the specific services and regions affected.

What are the most common reasons an SLA credit claim is denied? The most frequent denial reasons are: (1) claim submitted outside the allowable window; (2) the outage was attributed to a customer-side factor; (3) the service or configuration was not covered by the SLA; (4) insufficient documentation of the downtime period; and (5) the credit amount falls below the provider's minimum threshold.

Can I claim SLA credits across multiple cloud providers simultaneously? Yes. If you run a multi-cloud environment spanning AWS, Azure, GCP, Microsoft 365, and GitHub, you may have simultaneous SLA claims across multiple providers. Each provider's claims process is independent.

How much money are enterprises leaving on the table in unclaimed SLA credits? Cloud SLA credits are systematically underrecovered. Because claims require manual effort, tight deadlines, and detailed documentation, the vast majority of eligible credits are never filed. For large enterprises, even a modest number of SLA-eligible incidents can represent tens or hundreds of thousands of dollars in annual credits.