The SLA Credit Claim Process: How to File on AWS, Azure, and GCP

When a cloud service misses its uptime commitment, you are contractually owed a service credit. On AWS, Azure, and GCP alike, that credit is claim-only: the provider will never detect the breach or apply the money for you. This guide is the end-to-end filing process across all three, with the deadlines, the evidence each one wants, and how to submit so the credit actually reaches your invoice.

What an SLA credit is (and is not)

An SLA credit is not a cash refund. It is a percentage of the affected service's monthly charges, applied against a future bill, triggered when measured monthly uptime for that service falls below the published target. The percentage scales with severity, usually 10% for a mild miss up to 100% for a severe one, and it applies only to the service that breached, not your total account.

The number-one fact to internalize: credits are earned automatically but paid only on request. Independent CloudDowntime research finds that a large majority of outages that breach an SLA never turn into a claimed credit, purely because nobody filed in time.

Step 1: Confirm the breach

Convert your downtime into a monthly uptime percentage. For a 30-day month:

(43,200 - minutes down) / 43,200 * 100

Compare that against the affected service's target. Configuration matters: some commitments are region-level, so a single-zone event may not breach a regional SLA. When it is borderline, run it through the SLA credit calculators with your spend to see the tier and dollar amount before you invest time filing.

Step 2: Capture evidence the day it happens

Evidence decays fast, so collect it while the incident is live or fresh:

• The provider event: an AWS Health Dashboard event ID, an Azure Service Health entry, or a GCP incident from the status page.
• Your own monitoring graphs with clear timestamps showing the impact window.
• The specific affected resource IDs (instances, buckets, functions) and their regions.
• A handful of failed request IDs as concrete proof your workloads were hit.

"The region was down" is not a claim. "These resources in this region failed during this window" is.

Step 3: Know the deadline for your provider

Deadlines differ and they are hard cutoffs:

• AWS: by the end of the second billing cycle after the incident, roughly 60 days.
• Azure: within two months of the end of the billing month in which the incident occurred.
• GCP: generally notify support within 30 days of the incident.

Calendar the deadline the moment the outage resolves. Automating the trigger helps: outage tracking with real-time alerts flags the day an incident may have earned a credit, so the window never closes unnoticed.

Step 4: File through the right channel, worded like an invoice

Each provider has a specific path:

• AWS: open a case in the Support Center, subject line containing "SLA Credit Request."
• Azure: submit a support request under the billing category referencing the affected SLA.
• GCP: contact Cloud Billing Support and cite the incident and SLA.

In every case, state the figures factually: the SLA by name, the billing month, your measured uptime, the tier it lands in, and the exact credit amount requested against that service's charges. This is a contractual entitlement, not a favor, so keep the tone matter-of-fact and precise.

A useful template keeps every claim consistent: one line naming the service and its SLA target, one line stating the incident window and your measured uptime, one line naming the tier and the percentage it earns, and one line with the dollar figure against that service's monthly charges, followed by the evidence list. Reusing the same structure across AWS, Azure, and GCP makes each claim faster to write and easier for the reviewer to approve, and it gives you a paper trail you can audit later when you reconcile the credit on the invoice.

Step 5: Reconcile

Approval is not payment. An approved credit appears as a line item on a subsequent invoice, usually within one to two cycles. Verify the amount matches what you requested, and if it stalls, escalate through your technical account manager or account team. An approval you never confirm is worth nothing.

Common mistakes

• Claiming the whole bill. Credits apply to the affected service's charges only. Overclaiming slows the review.
• Missing the window. The most common failure by far, and it is unrecoverable.
• No resource-level evidence. Without proof your workloads were affected, the claim is weak.
• Filing every micro-blip. Below the breach threshold there is no credit; the calculator keeps you from wasting cases.

Go deeper

Provider-specific tiers and mechanics live in the AWS, Azure, and GCP playbooks. SLA credits are one half of cloud recovery; the billing-accuracy half is covered in how to audit your cloud bill, and both fit inside the broader discipline of FinOps fundamentals. More worked claims are on the blog. Our sponsor Next Signal watches your account for breaches and generates the claim plus a copy-paste support ticket, so the filing happens before the deadline instead of after it.