Free Tier and SLA Credits: When the $0 Bill Pays Out Nothing
October 3, 2026
Every cloud SLA credit is a percentage of what you actually paid. The AWS Compute SLA hands you a Service Credit calculated from "the monthly bill". Azure defines it as a percentage of "fees actually paid". Google caps the credit at "the amount due by Customer" for the month. Now look at your free tier usage: 750 hours of t3.micro at AWS, the e2-micro at Google, the App Service Free tier at Azure. The bill for all of it is $0.00. A percentage of $0.00 is $0.00.
That is the part nobody warns you about when they tell you to go claim your credits. An outage can breach the SLA, cross the credit tier, and still pay you nothing, because the credit base was zero. Azure goes further and says free-of-charge tiers are "not included or eligible for SLA claims or credits" at all. Before you spend an hour collecting evidence for a free workload, you need to know which of your usage can ever pay out.
The one rule that decides every claim
Every provider measures the credit against the money you were billed, never against the pain you felt. The formulas are short and worth reading in the original:
| Provider | Credit base, in the SLA's own words | Catch |
|---|---|---|
| AWS | Percentage of the monthly bill for EC2 in the affected region, or for the affected single instance (Compute SLA, May 2022) | Credits under $1 are not issued |
| Azure | Percentage of "Applicable Service Fees", the total fees actually paid (October 2026 consolidated SLA) | Free-of-charge tiers are not eligible for claims or credits |
| Google Cloud | Percentage of the monthly bill for the covered service in the region that missed the SLO (Compute Engine SLA, March 2025) | Maximum credit may not exceed the amount due for those services |
| DigitalOcean | Credit applies to the affected resource's charges (CPU Droplet SLA, June 2025) | No always-free tier exists to argue about |
Notice what is absent from every row: the number of minutes you were down, the customers you lost, the invoices you had to eat. None of it enters the formula. Only the fee does.
The clauses that kill free-tier claims outright
Azure is the only one of the four that says it in plain text. The introduction to the current consolidated SLA (the same October 2026 document that lists every service commitment) states: "Previews and Online Services and/or service tiers provided free of charge are not included or eligible for SLA claims or credits." That is a blanket answer. An App Service running on the Free or Shared tiers is not covered by the 99.95% commitment its paid cousins carry, and even if it were, the definition of Applicable Service Fees would hand you a percentage of $0.
Google reaches the same end through the back door. Every financial credit is capped: "The maximum aggregate number of Financial Credits issued by Google to Customer for all Downtime Periods in a single billing month will not exceed the amount due by Customer for the respective Covered Services." Your always-free e2-micro breaches its 99.9% single-instance commitment, the tier table says 10%, and the cap says 10% of the $0 you owed. The two clauses together are a perfect filter: free usage returns zero, paid usage returns a real number.
AWS never writes the word "free" into the Compute SLA, because it does not need to. The credit is a percentage of the monthly bill, and a free-tier instance contributes nothing to that bill. Two smaller rules stack on top. First, no credit is issued at all below $1, which quietly buries claims for small instances even when they are paid. Second, AWS already stops charging for any single instance that is unavailable for more than six minutes of a clock hour, so the automatic hourly waiver is the only "credit" a free instance will ever generate, and it credits a charge that never existed.
The money math, worked out
Same outage, same month, different billing status. This is what the formulas actually produce:
| Scenario | Outage | SLA math | Fees paid that month | Credit you receive |
|---|---|---|---|---|
| AWS t3.micro, free plan | 12 hours down | Instance-level 99.5% commitment: 98.36% uptime, 30% tier | $0.00 | $0.00 (30% of $0, and under the $1 floor anyway) |
| Azure App Service, Free tier | 8 hours down | No SLA exists for the tier | $0.00 | Nothing, by definition |
| Google e2-micro, Always Free | 8 hours down | Single instance 99.9% breached, 10% tier | $0.00 | $0.00 (10% of $0, capped at amount due) |
| Azure App Service, Basic tier | 8 hours down | 98.89% uptime, 25% tier | $55.00 | $13.75 |
| AWS t3.medium, paid, same region | 12 hours down | Instance-level 30% tier | $250.00 | $75.00 |
The top three rows are the trap. The outage was real, the SLA was breached, the tier table was crossed, and the payout is zero because the fee was zero. The bottom two rows show why the same effort on paid usage is worth the paperwork. The claim work is identical in all five cases: same evidence, same support case, same deadline. The only variable is whether the resource bills you.
When free usage still earns something
There are two cases where free usage rides along with real money, and both are worth understanding before you write off the whole idea.
First, mixed bills. AWS region-level credits are a percentage of the region's EC2 bill, not of individual instances. If you run paid instances in the same region as your free ones and a region-level breach happens, the credit is computed on the paid bill, and the free instances neither add to it nor subtract from it. The free tier does not dilute a claim. It just does not contribute one.
Second, grant overflow. Azure Functions on the Consumption plan has a real SLA, 99.95%, even though the first million executions a month are a grant. The credit is a percentage of the fees actually paid, so the grant portion bills $0 and earns $0, but the overflow you pay for is claimable. A month where you paid $4.00 in overflow and the plan missed its target earns 10% of that $4.00, not 10% of your imagination of what the outage cost.
One more exclusion hides in the Azure limitations list: downtime "with respect to purchases made using Microsoft subscription credits" is not covered. The $200 free-account credit is a subscription credit, so the period where it pays your bill is outside the SLA's reach, on top of the free-tier exclusion. Google's $300 trial credit works the same way through the amount-due cap: while the trial covers the bill, the amount due is $0, and the maximum credit is $0.
A service credit is a percentage of the fees you actually paid. Free usage bills zero dollars, so it produces a zero-dollar claim. If a workload runs free, it has no SLA protection you can collect, only an availability problem.
What to do with a free workload
The practical move is a billing audit, not a monitoring change. Open last month's invoice and tag every line that billed $0.00: always-free usage, trial credits, grant overflow that stayed under the limit. Those lines are now off your claim radar. Do not collect evidence for them, do not track their deadlines, do not file for them. The effort is identical to a real claim and the payout is structurally zero.
Then make one decision per $0 line. A dev or test resource can stay free and unprotected; that is a reasonable trade. A workload that faces customers or generates revenue should move to a paid tier, because the paid tier is the only version of it the SLA will ever pay for. The difference is not the uptime, which is the same hardware either way. The difference is that a paid resource enters the credit base, and an outage on it produces a number you can actually claim.
The deadlines still apply to the paid part, unchanged: AWS wants the claim by the end of the second billing cycle after the incident, Azure within 60 days of the incident, Compute Engine within 60 days of eligibility. Free usage does not pause those clocks, it just never starts them.
So the concrete step for today: pull last month's bill, mark every $0 line, and delete those resources from your claim tracker. Then take the one workload that actually matters and move it to a paid tier. That is the only version of it that can ever pay you back.