Serverless Container SLAs: What Fargate, Container Apps and Cloud Run Pay When the Container Fails
October 12, 2026
Fargate, Azure Container Apps and Cloud Run all owe you money when they fail, and each measures failure differently. Fargate promises 99.99% for a multi-AZ fleet and 99.5% for a single task or pod. Container Apps promises 99.95% per app. Cloud Run promises 99.95% but only counts a failure when more than 1% of valid requests return infrastructure errors. Those differences decide whether a 30-minute outage earns you $100 or $0 on a $1,000 monthly bill.
Three platforms, three different promises
The AWS contract is the curious one. The ECS and Fargate SLA, last updated May 25 2022, covers both ECS tasks and EKS pods running on Fargate, and it splits the promise in two. A multi-AZ deployment (tasks or pods spread across at least two AZs) gets a 99.99% Monthly Uptime Percentage. Each individual task or pod gets its own 99.5% promise. You can claim under either, but never both for the same resource.
Azure Container Apps keeps one flat 99.95% promise with a credit ladder that still reaches 100%, which is rarer than it sounds in the October 2026 consolidated SLA. Google's Cloud Run SLA, last modified March 25 2025, adds a wrinkle: downtime is not "the service was slow". It is a measured Error Rate, and only 5xx responses caused by Cloud Run infrastructure count.
| Platform | Uptime promise | A minute of downtime counts when | Credit tiers |
|---|---|---|---|
| Fargate, multi-AZ (ECS + EKS) | 99.99% | All running tasks or pods across 2+ AZs fail in the same 1-minute interval | 10% / 25% / 100% |
| Fargate, single task or pod | 99.5% | That one task or pod fails in a 1-minute interval | 10% / 25% / 100% |
| Azure Container Apps | 99.95% | An app has no connectivity to Microsoft's Internet gateway for a minute | 10% / 25% / 100% |
| Cloud Run, non-GPU | 99.95% (99.9% in Mexico and Stockholm) | More than 1% of valid requests return 5xx from Cloud Run infrastructure, with a minimum of 100 valid requests | 10% / 25% / 50% |
Two structural facts sit behind the table. Credits are a percentage of what you actually paid in the affected region and period: AWS credits the affected service or task in the affected region, Azure credits the Applicable Service Fees for the Applicable Period, Google credits the monthly bill for the covered service in the region. And in every case the platform's own failure definition is the gate. If your container crashed because your code threw, none of the three pays.
The breach math: minutes per month
Monthly uptime percentages are unforgiving at the 99.99% and 99.95% level. A 30-day month has 43,200 minutes, so the allowance between "fine" and "breach" is tiny.
| Commitment | Downtime that breaches | First credit tier |
|---|---|---|
| 99.99% | About 4.3 minutes per month | 10% |
| 99.95% | About 21.6 minutes per month | 10% |
| 99.5% | 216 minutes (3 hours 36 minutes) per month | 10% |
The deployment shape decides the claim before you fill in any form. On a $1,000 monthly bill, a 30-minute full-region fault pays $100 under Fargate's multi-AZ promise, $100 on Container Apps and $100 on Cloud Run, but $0 on a single Fargate task: 30 minutes is 99.93% for that task, comfortably above its 99.5% promise. Small apps, small credits, different math.
That gap matters in practice, so the money math on a $1,000 per month bill looks like this. The 4h 8m row is a real incident, detailed below.
| Outage length | Fargate multi-AZ | Fargate single task | Azure Container Apps | Cloud Run |
|---|---|---|---|---|
| 30 minutes | $100 | $0 | $100 | $100 |
| 4 hours 8 minutes | $100 | $100 | $100 | $100 |
| 8 hours | $250 | $250 | $250 | $250 |
| 40 hours | $1,000 | $1,000 | $1,000 | $500 |
The bottom row shows the true difference between the contracts. Below 95% monthly uptime, AWS and Azure pay the full monthly bill as a credit. Google caps every Cloud Run credit at 50% of the month, so the worst month on record is worth half. Fargate also adds a $1 floor: credits under one dollar are never issued, which quietly kills claims on tiny dev workloads.
The measurement rules that kill claims
Each platform writes its failure definition narrowly, and each has traps:
- Cloud Run counts only infrastructure 5xx. Requests that fail because of your container are excluded by the definition of Valid Requests, as are quota rejections listed in the Admin Console and errors from features still in pre-GA. Requests that took more than 60 seconds to process only count toward the Error Rate if your client followed the back-off rules: a minimum 1 second wait after the first error, doubling up to 32 seconds. A client hammering a dead endpoint can measure the outage out of existence.
- Cloud Run needs sustained error. Partial minutes and intermittent failures under one minute do not count at all, because Downtime Periods are measured in whole consecutive minutes. A service that flaps every 45 seconds never breaches, no matter how useless it feels.
- Container Apps measures connectivity, not errors. A minute is unavailable when an app has no connectivity to Microsoft's Internet gateway, and Deployment Minutes start from your own scale rules: an app scaled to zero is not expected to be active, so an idle app has no claim surface. The October 2026 SLA also caps the first tier at 99.95% with no zone-redundancy bonus; Container Apps is a single promise, full stop.
- Fargate multi-AZ requires everything down. The 99.99% clock only ticks when all running tasks or pods across two or more AZs fail in the same minute. Lose one AZ while the other survives and the multi-AZ promise holds; your dead tasks in the failed AZ only qualify under the 99.5% per-task promise once they cross 216 minutes in the month. And you cannot stack: the SLA forbids combining Multi-AZ and Task/Pod claims for the same task or pod.
The exclusions are the usual furniture: force majeure, your own equipment and software, suspension of the account, quota and capacity limits. Nothing here changes the core rule, which is that each platform counts availability in minutes or error rates, not in your customers' suffering.
Deadlines: the three clocks
The claim windows for these platforms match their parent clouds, and they are short.
| Provider | Claim window | Route | Required evidence |
|---|---|---|---|
| AWS (Fargate) | End of the second billing cycle after the incident | Support case with "Container Service SLA Credit Request" in the subject | Dates and times of each outage, task or pod resource IDs, AWS regions, request logs corroborating the failure |
| Azure (Container Apps) | 60 days from the incident | Portal support request, billing and refund category | Incident description, time and duration, affected app names, locations and user counts, error descriptions |
| Google (Cloud Run) | 30 days from eligibility | Google Cloud support, SLA credit request | Log files showing the Downtime Periods with dates and times |
Azure's Applicable Period for pay-as-you-go services is the 30 days before and including the incident, so the credit is a slice of roughly the previous month's fees, not the whole bill. Google applies approved credits within 60 days of the request and will not pay more than 50% of the month. AWS needs the credit to exceed $1 and will not transfer it to another account.
A live example: September 1, 2026
On September 1 2026 Google's service health pages logged a network service degradation in us-central1-b that hit multiple products including Cloud Run for 4 hours 8 minutes. That is 248 minutes. A Cloud Run service in us-central1 that actually saw more than 1% of its requests fail with infrastructure errors during that window sits at about 99.43% for September, deep inside the 10% tier, worth $100 on a $1,000 monthly Cloud Run bill in that region.
The clock is the lesson. Google's 30 days run from eligibility, not from the incident, and eligibility for a monthly measurement only exists once the month closes, effectively September 30. A September claim therefore expires around October 30 2026. The earlier August 20 2026 us-west1 incident, 1 hour 23 minutes on the same list, crossed its eligibility date at the end of August and is dead now. Thirty days from incident would have been September 19; thirty days from eligibility is the end of October. Teams that file "when they remember" are the teams that lose the August claims and barely save the September ones.
The same math applies in reverse on AWS. Fargate uses billing cycles, not calendar months: an incident in October must be claimed by the end of the second billing cycle after it, which usually means by late December. Azure's 60 days from the incident is the most forgiving of the three clocks.
What to do today
Pick your biggest serverless container bill, open the platform's status history and your request logs for the last 60 days, and check three things: did any incident window overlap your region, did your error count cross the platform's threshold, and is the claim window still open. For Cloud Run users with services in us-central1, the September 1 window is the one that still pays. File the credit request on Google's SLA contact form with the downtime logs attached; fifteen minutes of paperwork against a month of uptime that did not happen. If tracking three clocks across three providers sounds like a job by itself, that is the job UptimeAudit automates: watch the status feeds to the service and region level, and draft the claim with the evidence and the deadline when a promise is breached.