Which Error Codes Count as Downtime: What AWS, Azure and Google Actually Measure
October 21, 2026
Your monitoring was red for two hours, you filed an SLA claim, and the provider came back with "no breach." Nine times out of ten the reason sits in the error codes. Cloud SLAs only count specific failures of the provider's own systems, and most of what your logs capture never qualifies. This post lists the exact error definitions in the AWS, Azure and Google Cloud SLAs, so you can tell a claimable outage from a wasted support case before you spend an hour writing one.
Three rules that decide whether an error counts
- The failure has to be the provider's. A 502 returned by your own load balancer or a 504 from your API gateway is your outage, not theirs.
- Only named codes count. AWS's Lambda SLA counts requests that return 500 or 503 from Lambda itself. S3 counts "InternalError" and "ServiceUnavailable". Nothing else in your logs is on their list.
- Silent intervals are free. On AWS and Google, any 5-minute window where you made no requests is treated as 100 percent available. You cannot claim downtime you did not try to use.
How each provider defines a counted error
| Provider and service | What counts as downtime | What never counts |
|---|---|---|
| AWS Lambda | Any request returning 500 or 503 from Lambda itself | Custom 500/503 emitted by your function code, 4xx, 429 throttling |
| AWS S3 | 5xx "InternalError" (500) or "ServiceUnavailable" (503) on your requests | Client-side errors, 4xx, no-request intervals |
| AWS EC2 | No external connectivity to the instance (connectivity, not codes) | Errors from your application stack |
| Azure VMs and services | A minute where requests fail or return no success within 5 minutes | Your app's failures, quota-exceeded operations |
| Google Cloud Storage | Valid requests returning any HTTP 500-range code, with proper backoff | Repeated identical requests without 1s-to-32s backoff, quota errors |
| Google Compute Engine | Loss of external connectivity or persistent disk access, 1+ consecutive minutes | Partial minutes, your app's errors, quota errors |
AWS: named codes, and only the provider's
AWS defines downtime differently per service. Lambda's SLA says an "Error" is a request that returns 500 or 503, then explicitly carves out custom 500 and 503 codes your function code emits. A Lambda function that crashes and returns its own 503 is not an outage under the SLA. Only Lambda's own infrastructure errors count, which is why the claim paperwork asks for request logs rather than your application metrics.
S3 is narrower still. Its SLA measures "Error Rate" as requests answered with InternalError (500) or ServiceUnavailable (503), and monthly availability is 100 percent minus the average of those rates across 5-minute intervals. EC2 abandons codes altogether: downtime means "no external connectivity," so an unreachable instance earns a claim while an instance serving your own 500s does not.
The pattern on AWS: credits exist only when the failure happened at their layer, and you prove it with request logs showing their error codes, in 5-minute granularity, with dates and times, filed by the end of the second billing cycle after the incident.
Azure: success, not status codes
Azure's SLAs rarely name HTTP codes. Across the service portfolio the definition repeats as "no Success Code returned within 5 minutes" or "all attempts fail." A minute of downtime is a minute where your requests to the service did not succeed, timeouts included. That is broader than AWS in one direction: a request that hangs and times out counts, where AWS Lambda would not count a timeout at all. It is narrower in another: Azure still excludes everything caused by your own operations, including quota-exceeding actions and customer-initiated restarts.
Google: the 500-range, plus the backoff trap
Google's SLAs count requests with an HTTP status in the 500 range, but only failures caused by Google's own infrastructure, and only for requests that follow its back-off rules. Cloud Storage's SLA is blunt: "Repeated identical requests do not count towards the Error Rate unless they conform to the Back-off Requirements." Those start at a 1-second wait after the first error and double with each retry up to 32 seconds. Hammer a failing endpoint every 100ms and Google can discount your entire error rate.
Cloud Run adds a floor: error rate only starts counting once you have at least 100 valid requests, and a 5xx returned by your container code is excluded. Compute Engine skips codes entirely, like EC2: downtime is loss of external connectivity or persistent disk access, in one or more consecutive minutes, and partial minutes do not count.
Before you file, check who returned the error. A 502 from your own gateway is a $0 claim. A 500 or 503 from the provider's own systems, inside the claim window, with request logs, is real money.
What an outage actually pays
The table below assumes a 30-day month (43,200 minutes) and a $200 monthly bill for the affected service.
| Scenario | Counts as downtime? | Credit |
|---|---|---|
| Your app returns 503s because a database pool is exhausted | No | $0 |
| Your gateway returns 502s while the provider is healthy | No | $0 |
| Lambda returns 500/503s from your own function code for 30 minutes | No | $0 |
| Lambda infrastructure returns 500/503s for 30 minutes (99.93%) | Yes | 10% = $20 |
| Single EC2 instance unreachable for 8 hours (98.89%) | Yes | 10% = $20 |
| S3 returns ServiceUnavailable for 2 hours (99.72%) | Yes | 10% = $20 |
Two things worth noting about the tiers. First, most breaches land in the 10 percent tier: an 8-hour outage on a single instance is 98.89 percent, which clears the 99.0 percent floor for the 10 percent bracket on AWS. Second, the $1 minimum is real: AWS does not issue credits under a dollar, so small bills with small outages often pay nothing even when the math technically breaches.
What to log so a claim survives
- UTC timestamps and request IDs for every failed call, bucketed by 5-minute interval.
- Which layer failed. Lambda logs show whether the invocation failed before your code ran or returned a response your function produced.
- Your request volume during the window. Zero traffic means zero claim on AWS and Google.
- On Google, proof of exponential backoff: retry timestamps at 1s, 2s, 4s and beyond. Without it, identical repeated requests are discarded from the error rate.
Do this now
Pull up last month's incidents and sort the failed requests by whether they carried provider-side error codes. Anything that did is a live claim: AWS files by the end of the second billing cycle after the incident, Azure within 60 days, Google within 30 to 60 days of eligibility depending on the service. The clock is the one part of this that never negotiates.