What Counts as Evidence in an SLA Credit Claim

August 5, 2026

Every SLA credit claim comes down to whether you can prove the outage hit your resources. The four big providers answer that question differently, and they wrote the requirements into their SLA documents. AWS wants request logs that corroborate your outage. Azure wants a tenant GUID, an outage incident ID, and proof of impact. Google wants log files showing downtime periods with timestamps. DigitalOcean wants you to name the affected resource and hand over whatever supports its own calculation. This post walks through the evidence each provider accepts, straight from the SLA text, plus the traps that get claims rejected.

The baseline every provider expects

All four SLAs share a core list, even though the wording differs:

• Dates and times of each incident, in a stated time zone. UTC removes all doubt.
• Resource identifiers: account ID, tenant GUID, project ID, instance or cluster IDs.
• Request logs or error logs that document the failures.

None of them accept a screenshot of a status page on its own. That screenshot is useful supporting material, but every SLA asks for logs tied to your account. The status page shows the region was sick. Your logs show you were sick in it.

AWS: request logs, exact subject lines, and a disqualification clause

AWS writes the evidence requirements directly into each service SLA. For EC2, a Region-Level claim must include:

1. The words "Amazon Compute SLA Credit Request - Region-Level Claim" in the subject line.
2. The dates, times, and affected region of each unavailability incident.
3. The resource IDs for your EC2 instances.
4. Your request logs that document the errors and corroborate the claimed outage.

An Instance-Level claim uses the subject "Amazon Compute SLA Credit Request - Instance-Level Claim" and adds the availability zone plus any other data AWS needs to validate the outage.

Two details in the EC2 SLA deserve attention. First, the redaction instruction: AWS asks you to replace confidential or sensitive information with asterisks. Redacting is expected, not suspicious. Second, the consequence clause: "Your failure to provide the requested and other information as required above will disqualify you from receiving a Service Credit." Missing one field ends the claim.

S3 has a trap worth knowing. Its SLA defines error rate as InternalError and ServiceUnavailable responses divided by total requests in each 5-minute interval, and intervals with no requests are assumed to have a 0% error rate. If your application was not sending requests during the incident, you have no breach to prove. Your logs only count when you were actively using the service, so high-traffic workloads have an easier time collecting than quiet ones. That is a fact of the SLA, not a judgment on the outage.

Deadline: AWS must receive the claim by the end of the second billing cycle after the incident. An outage in March means the claim lands by the end of May. Credits under one dollar are not issued, so the math needs to clear that bar too.

Azure: tenant GUID, outage ID, and proof of impact

Microsoft's credit documentation lists the required information plainly: the customer tenant's GUID, the outage incident identifier, and proof that the customer encountered the outage and requested the credit.

The outage incident identifier comes from the Service Health page and follows a fixed format: a two-letter service prefix plus a number, like EX25194 for Exchange Online. Grab it while the incident is live. It is the piece of evidence people most often fail to record, and there is no good way to recover it after the fact.

For impact proof, Microsoft wants specifics: the time and duration of the downtime, the number and locations of affected users, what you tried to resolve the incident, the support ticket number, and an email from the affected customer. That last one has a sharp edge. The email must come from the affected tenant's domain. Personal addresses are rejected outright.

One nuance: advisory incidents are typically not eligible for SLA credits. Microsoft distinguishes between a health advisory and a confirmed service degradation, and only the latter produces credits. If the incident stayed in advisory status, collecting evidence is wasted effort.

The Azure claim window is two months from the end of the billing month in which the incident occurred.

Google Cloud: log files, and windows that vary by service

Google's SLAs are consistent about one thing: you must notify technical support within a fixed window and provide log files showing the downtime periods with their dates and times. Fail, and the credit is forfeited. The SLA language is blunt about it.

The window is where you need to be careful. Cloud Storage and BigQuery say 30 days from the time you become eligible. Compute Engine currently says 60 days. Check the SLA page for the specific service before you assume, and put the date on a calendar either way.

Google also defines downtime narrowly, and the definitions matter for evidence. BigQuery counts a downtime period as ten consecutive minutes with an error rate above 5%. Compute Engine counts one-minute periods, and partial minutes or intermittent downtime under a minute does not count at all. Slice your log evidence by the exact period definitions in the SLA for that service.

There is a retry-loop trap too. Google's SLAs say repeated identical requests do not count toward error rates unless they follow the backoff requirements: a minimum 1-second interval, doubling up to 32 seconds. An aggressive retry loop does not build evidence. It invalidates it.

DigitalOcean: name the resource, show the logs

DigitalOcean's SLA language mirrors AWS closely. A claim must identify the affected resource (the App Platform SLA names the App Component Instance), give the dates and times of each unavailable incident, and include request logs that document the claimed outage plus any other available supporting evidence of the monthly uptime percentage.

Two things stand out. DigitalOcean calculates the uptime percentage itself, in its own "good faith determination," and issues the credit within one billing cycle after confirmation. Your logs support the claim; they do not set the number. And unavailability only starts after 5 consecutive minutes without external connectivity, so a handful of one-minute blips does not reach the bar.

Deadline: the end of the second billing cycle after the failure.

Build the evidence file before the outage

Claims fail in one of two places: missing evidence, or missed deadlines. Both are fixable before an incident happens. Keep a folder or a shared doc with this template:

The evidence file is won before the outage starts. Incident IDs and status page captures only exist while the incident is live, and every provider on this list asks for them. Collect those first, and the rest of the file writes itself.

During an outage, do these in order: note the UTC start time, screenshot the status page and the incident ID, run your error log query, and save the output. The Wayback Machine often holds status page captures if you miss the screenshot, but do not rely on it.

The one query worth setting up today: in CloudWatch, Cloud Logging, or Azure Monitor, build a query that returns your error rate per 5-minute interval for a service you depend on. Save it. Bookmark it. When an incident is declared, you run one command and your evidence file is half done. If you would rather not assemble this by hand, UptimeAudit keeps the evidence file for the services it monitors and drafts the claim when a threshold is crossed. Either way, the SLA text tells you exactly what to collect. It is a short list, and it is the same list every month.