Cloud SLA credits are a contractual adjustment to a qualifying cloud bill after availability falls below the provider’s stated commitment. An application being offline does not, by itself, prove that a credit is due. The agreement defines the service, failure condition, measurement period, exclusions and claim process.
For an operator, the useful question is how an incident maps to those terms. That can produce a much smaller amount than the business lost while customers could not use the application. The example below uses the Amazon Compute Service Level Agreement, checked October 7, 2026, to show the calculation and paperwork. Other services and providers have their own agreements.
Start with the service and the deployment
AWS makes separate availability commitments for an individual EC2 instance and for qualifying deployments across availability zones. In its region-level agreement, the monthly target is 99.99%. For an individual instance, the target is 99.5%.
The region-level commitment requires the deployment described in the contract: running instances across two or more availability zones in the same region, with a separate provision for a region that has only one zone. Buying a single instance does not automatically give the application the region-level commitment.
The definition of unavailability also matters. For the individual-instance agreement, AWS uses the absence of external connectivity. For the region-level agreement, it requires the qualifying running instances to lose external connectivity concurrently. An application error, an overloaded database or a broken deployment is not interchangeable with that definition.
Before calculating anything, identify the account, resource IDs, affected region, availability zones and the actual service agreement. A headline on a status page can help explain an incident, but it is not a substitute for evidence about the resources you operated. Our guide to reading a post-incident report shows how to separate a provider’s incident timeline from the effects on a particular application.
Calculate qualifying downtime over the billing period
An SLA can use a monthly percentage even when an incident lasts only a short part of one day. AWS calculates uptime by subtracting the percentage of unavailable minutes during the month from 100%.
Consider an illustrative 30-day month containing 43,200 minutes. If 60 minutes qualify as unavailability under the relevant agreement, the simple calculation is:
100 × (1 − 60 ÷ 43,200) = 99.8611% uptime
That example is arithmetic, not a finding about a real outage. The operator must still establish that the minutes count under the contract and are not excluded.
Under the EC2 region-level schedule, uptime below 99.99% but at least 99% corresponds to a 10% service credit. Below 99% but at least 95% corresponds to 30%; below 95% corresponds to 100%. The single-instance schedule starts at a different boundary: below 99.5% but at least 99% gives 10%, with the same lower bands.
A reader comparing those percentages should keep the deployment requirement beside the number. The higher commitment and the lower commitment apply to different configurations and failure definitions.
Apply the percentage to the eligible bill
AWS applies the region-level credit percentage to the affected region’s qualifying monthly EC2 bill, excluding one-time payments such as upfront Reserved Instance payments. For an instance-level claim, the base is the qualifying bill for the affected instance.
Suppose the eligible bill is $1,000 and a valid claim falls into the 10% band. The illustrative credit is $100. It is not 10% of the organization’s entire AWS account, annual budget, customer revenue or estimated outage loss.
AWS generally applies service credits against future EC2 payments. Its agreement says credits do not create an entitlement to a refund or other payment, cannot be transferred between accounts, and are issued only when the applicable credit exceeds $1.
The contract also contains a separate automatic billing rule for a single instance unavailable for more than six minutes in a clock hour. That rule should not be confused with submitting a monthly service-credit claim. AWS says no request is needed for that hourly adjustment.
A claim needs evidence and a deadline
For an EC2 SLA claim, AWS requires a case in its Support Center by the end of the second billing cycle after the incident. The subject must identify the relevant region-level or instance-level claim.
The request includes incident dates and times, the affected region, resource IDs and logs that substantiate the outage. Instance-level requests also identify the availability zone and include other data needed to validate the incident. AWS asks customers to replace sensitive or confidential material with asterisks.
Keep timestamps with their timezone and preserve the original records. A screenshot showing an application unavailable may be useful operational context, but it may not establish the contract’s connectivity condition for every affected resource.
AWS says a valid claim leads to a credit within one billing cycle after the month in which the request is confirmed. The region-level and instance-level claims cannot be stacked for the same individual instance.
Check exclusions before treating the amount as recoverable
The EC2 agreement excludes specified problems outside AWS’s control, customer actions or inaction, customer equipment or software, and suspension or termination under the governing agreement. It also distinguishes failures outside the metrics used for its uptime calculation.
This is why an incident record should keep the contractual assessment separate from the operational post-mortem. The engineering team may find that the application failed because it lacked redundancy, exhausted a connection pool or depended on a service outside this SLA’s scope. That finding can still justify a repair even when it does not support a credit.
Archive the agreement used, the resource and billing evidence, the calculation, the support case and the provider’s decision. A credit answers a billing question. The separate reliability review decides what should change before the next failure.
Source: AWS, Amazon Compute Service Level Agreement, last updated May 25, 2022; current page checked October 7, 2026. Amounts and downtime in the worked example are hypothetical.
