Serverless SLA Credits: Lambda, Azure Functions, and Cloud Run Functions Compared
September 14, 2026
Your serverless functions carry a stronger uptime promise than most of your virtual machines: 99.95% on all three platforms, with credits of 10% to 100% of the bill when the number is missed. But each provider measures that 99.95% with a different ruler, and the measurement decides whether an outage pays anything at all. The same incident can yield a 25% credit on one platform and nothing on another. Here is what each of them counts, what they exclude, and what a claim is actually worth on a serverless bill.
All three promise 99.95%. None of them measure it the same way
The credit tiers share a shape. AWS and Azure pay 10% of the monthly bill when uptime dips below 99.95%, 25% below 99.0%, and 100% below 95.0%. Google pays 10%, 25%, and 50%, and caps the total month at 50% of the bill. The difference is what feeds the calculation.
| Platform | Commitment | Credit tiers | What is measured |
|---|---|---|---|
| AWS Lambda | 99.95% per region | 10% / 25% / 100% | Request error rate in 5-minute windows |
| Azure Functions, Consumption plan | 99.95% | 10% / 25% / 100% | Executions that fail to run after a trigger fires |
| Azure Functions, Flex, Premium, App Service | 99.95% | 10% / 25% / 100% | Minutes the app can be triggered |
| Cloud Run functions (GCP) | 99.95% per project | 10% / 25% / 50% | Minutes with an error rate above 10% |
A 99.95% commitment allows about 22 minutes of downtime in a 31-day month (744 hours times 0.05%). Any more than that and a credit tier triggers. The outage does not need to be dramatic: a regional control-plane hiccup on a busy day clears the bar easily.
The no-traffic loophole decides most claims
Read the measurement definitions closely and a pattern appears: uptime is only measured while you have traffic.
Lambda computes Availability per 5-minute interval as the share of requests that did not fail with an error. If you sent no requests in an interval, that interval counts as 100% available. A two-hour Lambda API failure in the middle of the night, with no traffic from your account, records zero downtime. Your claim must list the dates, times, and availabilities of every 5-minute interval under 100%, so quiet windows are visible to AWS the moment you file.
Azure Functions on the Consumption plan is measured in executions. An execution is "unavailable" only when a trigger fired and the Function App history log captured no output five minutes later. Executions that ran and threw an exception still logged output, so they count as available. On Flex, Premium, or App Service plans the measurement switches to minutes the app can be triggered, which is a connectivity check between your plan and Microsoft's gateway.
Cloud Run functions defines downtime as a full minute with an error rate above 10%, where an error is a SYSTEM_ERROR result and Google only measures when there were at least 100 attempted executions in the period. Below 100 executions the platform's error rate is effectively unmeasurable, and partial minutes or intermittent errors under a minute are discarded.
The serverless SLA is a promise about the platform's error rate while your traffic is flowing, not a promise about your functions. Quiet windows, your code's 5xx responses, and throttling are excluded on every platform. Before filing, confirm the failure was platform-side, that you had traffic during the window, and that the credit clears the payout floor.
Your code never counts
Each provider writes the same exclusion in its own language. Lambda's SLA defines an Error as a request returning 500 or 503, except custom 500 or 503 codes your function returns. Your function throwing a 500 is not a Lambda error, and the exclusions also cover "not following the best practices described in the Lambda User Guide" and misconfigured VPC, security group, or credential settings. Azure excludes quota throttling and any use inconsistent with published documentation. Google counts only SYSTEM_ERROR results and explicitly excludes "quotas applied by the system."
The practical result: the failures that look like a serverless outage from the application side, timeouts, app exceptions, cold-start latency spikes, throttling at the concurrency limit, are not claimable on any of the three. Only platform-level failures count, and only while your requests were actually reaching the platform.
The money math: credits are a percentage of the functions bill
Credits are computed against what you paid for the function service in the affected region that month, not your whole cloud bill. Serverless bills are small, so credits are small. AWS states it will not issue a credit under $1 for the monthly cycle. Google caps the month's total at 50% of the bill and Microsoft's SLA text states no dollar floor, though credits still apply only to the affected service's fees.
| Monthly function bill | Tier triggered | Credit | Paid out |
|---|---|---|---|
| $400 (Lambda, one region) | 25% | $100 | Yes |
| $60 (Cloud Run functions) | 25% | $15 | Yes, under the 50% cap |
| $12 (Lambda) | 10% | $1.20 | Yes, just over the $1 floor |
| $8 (Lambda) | 10% | $0.80 | No, under the $1 floor |
| $5 (Azure Functions) | 10% | $0.50 | Yes if validated, no floor stated |
The October 20, 2025 us-east-1 incident shows the math in the wild. A race condition in AWS's DNS automation emptied the DynamoDB regional endpoint record, broad impact ran about 15 hours, and AWS's post-incident summary lists Lambda among the affected services, with most services restored around 4:50 PM ET. Fifteen hours in the 744-hour month is a 97.98% monthly uptime for anyone whose Lambda invocations failed through the window: below the 99.0% line, so the 25% tier applies. A $400 monthly Lambda bill in us-east-1 earns $100 in credits. A $12 bill earns $3. An $8 bill earns nothing: a 10% credit is $0.80, under the $1 floor.
Deadlines and filing routes
The windows are short and they do not start on the day of the outage.
| Platform | Deadline | Channel | What to include |
|---|---|---|---|
| AWS Lambda | End of the second billing cycle after the incident, about 60 days | AWS Support Center case, subject "SLA Credit Request" | Billing cycle, region, monthly uptime percentage, 5-minute interval data, request logs |
| Azure Functions | Two months after the end of the billing month of the incident | Azure support request, billing or refund type | Incident description, time and duration, affected resources, resolution attempts |
| Cloud Run functions | 30 days from the moment you become eligible | Google Cloud SLA contact form | Log files showing downtime periods with timestamps |
AWS wants the granular 5-minute interval record, which means you need request logs preserved from before the outage. Google starts its clock at eligibility, not at month end, so a mid-month incident shortens the effective window. Azure's two months from billing month end is the most forgiving window of the three.
What to do this month
Settle the three questions the SLA answers for you: how much do you spend on functions per region, which plan are your functions on, and how long do you keep invocation logs. Spend under $20 a month per region makes a 10% claim worth less than the hour it takes to file; wait for the 100% tier in that case. Above that, the filing is mechanical: calendar entries for each provider's window, logs kept for 60 days, and the claim drafted while the incident is fresh. The deadline tracking is the part that usually fails, and it is the part UptimeAudit automates: it watches provider health feeds for your services and regions, drafts the claim when observed downtime crosses a threshold, and counts down the window. The SLAs are already written. The credits are already owed. The only variable is whether anyone files.