← Back to Blog

Cloud Credits Are Not Cash: How AWS, Azure, GCP, and DigitalOcean Actually Pay Out SLA Credits

August 13, 2026

Your cloud provider breaches its uptime SLA, you file the claim, and a week later the reply lands: a credit has been applied. No check, no transfer, no cash. What actually hits your account is a discount on a future bill, for the service that broke, often a month or more after you asked, and sometimes less than you expected. The distance between "credit" and "cash" is where most people get surprised. This guide explains, provider by provider, what a service credit really is, when you see it on a bill, and what it can and cannot do.

A brass balance scale with a small stack of gold coins on one pan and a stack of blank paper credit slips on the other, showing the difference between cash and cloud service credits

What a service credit actually is

A service credit is a dollar amount calculated against what you paid for the affected service, then applied to future usage. It is a discount, not money coming back to you. Every one of the big four writes some version of that rule into its SLA. AWS is the bluntest about it: "Service Credits will not entitle you to any refund or other payment from AWS."

The payout mechanics differ enough that one table is worth keeping on hand.

ProviderWhat the credit isApplied toWhen you see it
AWSPercentage of the monthly bill for the affected service in the affected regionFuture payments for that serviceWithin one billing cycle after AWS confirms the claim; only issued if over $1
AzurePercentage of the monthly service fee for the affected serviceFuture invoices as a creditAfter Microsoft approves the request, filed within two months of the billing month
Google CloudA "financial credit," a monetary credit in dollarsFuture use of the covered serviceWithin 60 days of your credit request
DigitalOceanA credit in USD on your accountYour DigitalOcean account balanceIn the billing cycle following the one in which you filed

The short version: every provider gives you a discount on a future bill for the same service. None of them cut you a check.

The fine print that changes the amount

Once you stop reading "credit" as "cash," a few rules in the small print start to matter.

Credits do not transfer. AWS states that service credits "may not be transferred or applied to any other account." If you close the account, the credit goes with it. Google and DigitalOcean issue credits against the specific covered service or account, so a credit does not follow you across a reorganization.

Credits are tied to the service. A credit for EC2 does not touch your S3 bill. Google's SLA is explicit that a financial credit applies to "future use of the Covered Service." If your outage hit two services, you are looking at two separate claims and two separate credit lines.

Minimums exist. AWS will not issue a credit for an amount of one dollar or less. For small accounts a single incident rarely crosses that line, which is exactly how a breach worth $0.40 evaporates.

Timing lags. You do not see the credit when the outage ends. AWS issues it within one billing cycle after the claim is confirmed, Google within 60 days of your request, and DigitalOcean in the billing cycle after you file. If your finance team is closing the books on the outage month, expect the credit to show up on the following month's statement instead.

A service credit is a discount on the same service's future bill, not a refund. AWS says it plainly: "Service Credits will not entitle you to any refund or other payment from AWS." Set expectations there and the payout process stops being a surprise.

The one credit you never have to claim

Most service credits require a support case, evidence, and a deadline. AWS has one that does not. Under its Instance-Level SLA, AWS will not charge you for any single EC2 instance that is unavailable for more than six minutes of a clock hour. That credit applies automatically: no claim, no deadline, no evidence. The unusable hour simply disappears from your bill.

It is the rare part of the SLA that behaves like a refund, and it is easy to miss because most engineers assume every credit needs a claim. If an instance dropped for more than six minutes in a given hour, check that hour on your bill before you file anything for it.

The money math

Even an approved credit is often smaller than the damage it is compensating for. Consider the October 2025 AWS outage in us-east-1, which left uptime for the month around 98% for affected accounts. One published analysis walked through a fund spending $50,000 a month in that region: with monthly uptime below 99.0% but above 95.0%, it qualified for the 30% tier, a credit of roughly $15,000.

That is real money, but it is a discount on one region's service spend, and it does nothing for what the outage cost in missed trades or lost revenue. The 100% tier, essentially a full month's fee for the service, requires monthly uptime below 95.0%, which at a 99.99% commitment means about 36 hours of downtime in a month. Most outages, including the ones that make the news, land in the smaller tiers.

Set expectations, then verify

Because credits are slow and service-specific, do not budget for them as cash. Treat them as a small, delayed discount on a particular line. A few habits make the process painless:

  • Keep the provider's SLA page for each service you run, so you know the commitment and the tiers before an incident happens.
  • After an outage, note the exact impact window with timestamps, then compare the month's uptime against the tiers.
  • If a claim is approved, check that the credit appears in the billing cycle the provider promised. If it does not, follow up while the window is still open.

The claim itself is usually under an hour of work once you know the outage happened, hit your services and regions, and crossed a tier. The part people lose is the timing: the deadline, the wait for the credit, the follow-up. If you want a signal the moment an outage crosses a tier you pay for, that is the one thing UptimeAudit watches for on your behalf.

One concrete step before you close this tab: open your billing console and look at the month of your last real outage. Did a credit land for that service in the following cycle? If the outage breached the SLA tier and nothing showed up, the claim window may still be open. File it before it closes, and remember the credit is a discount on a future bill, not cash in the bank.