How to claim AWS service credits in four steps — a practical playbook for SaaS finance teams

Every quarter, lean SaaS teams leave meaningful money on the table with AWS. Service credits are public, contractual, and recoverable — but they are also easy to miss, slow to post, and rarely filter up from the technical on-call into the finance queue. The pattern that closes the gap is unglamorous: gather the right evidence, match it to the credit policy at the precise sub-section, file once with that context attached, and follow up on a cadence until the credit lands on the next invoice. This guide walks through that pattern, end to end.

You can run the playbook by hand. You can also wire it into an agent that watches your AWS Health events, posts to Slack for sign-off, and runs the entire loop while your team sleeps. Either way, the four steps below are the same.

Step 1 — Confirm the incident meets AWS’s credit policy

Not every AWS issue is a credit-bearing incident. Before opening a case, you want a clean rubric that maps the outage to a specific clause of the AWS Service Level Agreement. Skipping this step is the most common reason claims get closed without a credit: the case reads as a generic issue report, not as a contractual SLA breach.

Three things must be true at once:

• The service in question has a published SLA with a credit schedule you can quote (EC2, RDS, DynamoDB, Lambda, S3, CloudFront, Route 53, and most others do — check the current Service Level Agreements page).
• Your measured availability for the affected region and service fell below the SLA threshold during the incident window. Note the exact percentage and the measurement interval the SLA defines (typically monthly, sometimes per-request or per-Region).
• The service was generally available through AWS — i.e. the outage was on the AWS side, not on your VPC, IAM, code, or configuration. If the root cause is yours, the SLA does not apply.

AWS Health Dashboard is the authoritative source for AWS-side incidents. Cross-reference the window against the service in your claim (Region, AZ, service code). When AWS publishes a Health event that matches your window, screenshot the page and save the URL — it is the single strongest piece of evidence in the case.

Step 2 — Assemble the evidence pack

A well-evidenced case is the difference between a one-week response and a back-and-forth that drags for six weeks. Build the evidence as a folder, not as an inline email: AWS Support accepts attachments, and a tidy pack makes the reviewer’s job faster than re-checking your numbers.

A complete pack contains:

• The AWS Health event (event ARN, start/end timestamps, affected resources, AWS-side acknowledgement).
• A CloudWatch metrics export for the affected service over the incident window — request count, error rate, latency p50/p95/p99, throttles. Export as CSV, not screenshots; CSV is auditable.
• The exact availability percentage your service posted during the incident, computed in the way the SLA specifies. Show the math in a one-page summary.
• A timeline of customer impact: tickets opened, status-page events, support volume, refunds issued, SEV-1 / SEV-2 declared. Anything that proves real users felt the outage.
• The matching SLA clause: service name, SLA URL, the specific credit tier and the percentage credit owed, and your invoice month so the reviewer can apply the credit to the right statement.

The case reviewer is reading ten other cases today. If your availability number is in the first paragraph and the SLA clause is cited by URL in the second, the review goes one way. If they have to hunt, the case gets closed unceremoniously.

Step 3 — File the case through AWS Support with the right context

Open the case from the AWS Support Center, category: “Service availability / SLA.” Pricing plan matters here: Developer and Basic plans cannot file for service credits as a separate case type, so if you are on a lower tier, the credit request has to ride on a technical support case. Business and Enterprise On-Ramp / Enterprise plans get the dedicated credit channel.

In the body of the case, lead with what the reviewer needs:

• One sentence: which service, which Region, what your measured availability was for the window.
• Second sentence: the SLA clause you are claiming against (URL + the credit schedule row).
• Third sentence: the customer-impact summary, in dollars or users affected, whichever is more convincing for your business.
• Then the evidence pack as attachments, with the filenames labelled so they read in order (01-health-event.pdf, 02-cloudwatch-export.csv, 03-availability-summary.md, 04-impact-summary.md).
• Close with a single, specific ask: “Apply a <X>% credit to the <month> invoice per the <service> SLA, tier <Y>.” Vague asks produce vague replies.

A useful shortcut for technical leads is to stamp a small JSON manifest onto the case so the reviewer can paste the timestamps and ARNs into the AWS internal tooling without retyping:

{
  "service": "Amazon RDS for PostgreSQL",
  "region": "us-east-1",
  "slaUrl": "https://aws.amazon.com/rds/sla/",
  "slaClause": "RDS Single-AZ Multi-AZ Monthly Uptime ≥ 99.95%",
  "measuredUptimePct": 99.71,
  "creditTierPct": 25,
  "invoiceMonth": "2026-07",
  "healthEventArn": "arn:aws:health:us-east-1::event/RDS/AWS_RDS_OPERATIONAL_NOTIFICATION/AWS-RDS-OP-NOT-2026-07-14-001",
  "windowUtc": { "start": "2026-07-14T09:41:00Z", "end": "2026-07-14T11:08:00Z" }
}

Step 4 — Run the follow-up cadence until the credit posts

AWS rarely closes a credit case on the first reply. The cadence that works across hundreds of cases is short, predictable, and polite:

1. Day 3 after the case opens: if there is no acknowledgement, reply once with the evidence pack repeated in-line and a “gentle bump.” Most reviews move at this point.
2. Day 7: if the reviewer is still asking for the same evidence, escalate within your plan — reply “Escalating per SLA tier X,” attach the original message ID, and request the TAM if you are on Enterprise.
3. Day 14: if the case is still open without a clear credit decision, request the credit determination in writing. Reply with a one-line summary of where the review stands, including any reviewer objections, and ask for the credit calculation shown line by line.
4. Day 30: if the credit has been approved but not posted, follow up with a reference to the determination and ask for the invoice-on-which-it-lands date. AWS finance teams need that nudge.

Track every case in a single ledger — case ID, service, claim amount, status, last contact, next action. The ledger is what makes the recovery loop auditable for finance and transparent for engineering. Most teams do this in a shared spreadsheet; a few have moved it into a queue that the ops agent owns end-to-end.

Closing notes

The four steps are the same whether you file one case a year or one a week. The lift is small — most credit-bearing incidents at a typical SaaS company resolve into a five-figure recovery over a quarter — but the lift is per-incident, every incident, all year. The teams that get the money are the ones that turn it into a queue the finance lead owns, with a vocabulary (one rubric, one evidence folder shape, one cadence) that everyone can run without re-deriving it.

Recoupfox is built to be that queue. It watches AWS Health for events that match your stack, drafts the case with the rubric and evidence baked in, queues it to your Slack for sign-off, and then runs the cadence for you until the credit posts. If you would rather a vigilant agent handle the loop, get a Recoupfox for your stack.