A denied SLA credit claim almost never means the credit was not owed. It usually means the claim was filed wrong. Providers process these requests against a checklist, and a claim that misses one item gets bounced, often without a clear explanation. The good news: the failure modes are predictable. Avoid these seven and your approval rate climbs sharply.
If you want to sanity-check the underlying numbers before you file, our SLA calculator confirms the tier your downtime lands in.
1. Missing the claim window
This is the single most common reason credits are forfeited, and it is unforgiving. The clock starts at the incident, not when you notice it.
- AWS: open a support case within roughly 60 days of the billing period.
- Azure: submit within two months of the end of the billing month.
- Google Cloud: notify technical support within 30 days.
Miss the window and the money is gone, no matter how clear the breach. If you cannot file immediately, at least log the incident so the deadline is on someone's calendar.
2. Applying the wrong SLA to the wrong service
Every service has its own SLA, its own target, and its own tier table. A common mistake is quoting the wrong document: citing a general "cloud uptime" figure when the affected resource is governed by a specific service SLA with a different number. Name the exact SLA that covers the affected resource, and cite its published target. Our guide to reading SLA fine print explains how to find the right document.
3. Claiming across the wrong scope
Credits are calculated per service, per billing month, against that service's charges. Two scope errors sink claims:
- Over-scoping: asking for a credit against your whole bill when only one service breached. The provider will only credit the affected service line.
- Region and zone confusion: claiming a region-wide credit for an incident that only affected one availability zone, when your SLA measures availability differently. Match the outage's actual blast radius to how the SLA defines impact.
4. Thin or expired evidence
"There was an outage" is not a claim. You need to show measured unavailability of your resources. Providers weigh evidence, and dashboards age out fast, so capture it early:
- Provider status and health history for the incident, with timestamps.
- Your own monitoring graphs showing the failure window.
- Affected resource IDs and error logs.
- The measured uptime percentage you calculated for the month.
Our evidence checklist details exactly what to grab and when. Capturing it within days of the incident is the difference between a strong claim and a hand-wave.
5. Getting the uptime math wrong
The tier depends on a precise number, and rounding or sloppy arithmetic invites rejection. The calculation is simple:
uptime % = (total minutes in month - impacted minutes) / total minutes in month
Use the actual minute count for that specific month, not a generic 30-day figure, and count only the minutes your resources were genuinely unavailable. A claim that says "about 98%" is weaker than one that says "97.6%, which falls in the 25% credit tier." Show your work.
6. Claiming losses instead of credits
An SLA credit is a percentage of the service bill. It is not compensation for lost revenue, missed deadlines, or engineering hours. Claims that ask for business damages get denied because they ask for something the SLA does not offer. Frame the request as what it is: a service credit against the affected month's charges, at the tier your uptime lands in.
7. Giving up after the first response
Providers sometimes push back on the first reply, especially if they never posted a public incident. That is not a final answer. Your own monitoring data is valid evidence, and the SLA is about measured availability of your resources, not about whether the provider announced anything. If the first response stalls, escalate through your account team with the same figures. Persistence recovers a lot of "denied" claims.
A quick pre-flight checklist
Before you hit submit, confirm every one of these:
| Check | Why it matters |
|---|---|
| Inside the claim window | Late claims are auto-forfeited |
| Correct SLA named | Wrong document invalidates the tier |
| Scoped to the affected service | Over-scoped claims get trimmed to zero |
| Evidence captured and timestamped | Thin proof gets bounced |
| Uptime math shown precisely | Vague numbers weaken the tier |
| Request framed as a credit | Loss claims are out of scope |
Do it once, do it right
The pattern behind every denied claim is haste or missing detail. Slow down for one afternoon, follow the checklist, and the approval rate takes care of itself. For the full submission walkthrough, see our how-it-works overview and the step-by-step filing guide.
If you would rather not track windows and evidence by hand, Cloud Credits covers the billing-accuracy angle, live outage data lives at Cloud Downtime, and Next Signal (our sponsor) automates detection, evidence, and claim drafting end to end. Either way, run your numbers first.
