What Is an SLA Credit and How Do You Claim One? The Five-Step Claim
An SLA credit is a contractual remedy in which a provider credits back a percentage of your fee when measured availability falls below the level they committed to. Two things about it surprise people. It is almost never paid automatically, so you have to notice the breach and file a claim, and it is usually credit against future invoices rather than money returned, capped at a fraction of what you paid.
This article covers what a credit actually is, the five steps a claim has to clear, the deadlines that quietly disqualify most claims, and why the evidence you bring determines the outcome. The recurring theme is that credits are designed to be claimable and not designed to be easy.
What an SLA credit actually is
The structure is consistent across the major providers even though the numbers vary. The agreement commits to a level of availability over a billing period. If measured availability falls below it, you become eligible for a credit expressed as a percentage of the fees for the affected service in that period, stepping up as availability falls further. Microsoft's published tiers are a representative example: falling below 99.9% but staying at or above 99% earns a 25% credit, below 99% but at or above 95% earns 50%, and below 95% earns 100%.
Three limitations matter more than the percentages.
It is a credit, not a refund. It is applied against future invoices, which means it has value only if you remain a customer. Leaving because of the outage generally forfeits it.
It is capped at your spend, not your loss. A credit is a proportion of what you paid for that service in that period. If an outage cost you far more in lost revenue than your monthly bill, the credit does not approach it, and it is not intended to.
It is usually the sole remedy. Most agreements state explicitly that service credits are your exclusive remedy for unavailability, which forecloses other claims. That clause is standard and worth knowing about before an incident rather than after.
The five-step claim
Call this the five-step claim, and a failure at any step ends it.
Establish the breach. Apply the agreement's own availability formula to the period, using the units it specifies, and subtract anything the exclusions remove. Compare the result to the committed figure. If you are above the committed threshold, there is no claim regardless of how bad the outage felt.
Assemble evidence. Timestamps for the start and end of unavailability, the nature of the failure, and ideally independent measurement. The provider's own incident timeline frequently understates customer-visible duration, because it starts when they acknowledged the problem rather than when it began.
Check the deadline. This is where most claims die and it is covered in the next section.
File through the specified channel. Providers require claims through a particular route, typically a support portal or a formal request form, and a claim raised in the wrong place may not count as filed at all. Following the documented procedure matters.
Wait for confirmation. The provider verifies against their own measurements. Where their figures differ from yours, independent monitoring data is what makes the difference between a negotiation and a rejection.
Our guide to uptime and SLA monitoring covers the measurement side that steps one and two depend on.
The deadlines, and why they are the real filter
Every agreement sets a window, and missing it forfeits the credit regardless of how severe the outage was. The windows are shorter than people expect and they vary meaningfully.
AWS requires credit requests by the end of the second billing cycle after the incident. Google Cloud requires customers to notify support within 60 days of becoming eligible, with log files showing the downtime periods and their dates and times. Microsoft 365 typically requires submission within 30 days following the month in which the incident occurred. Windows in the 30 to 60 day range are the norm, and some providers set them as short as a fortnight.
The practical problem is not that the windows are unreasonable. It is that nobody owns the task. The outage is handled by engineering, the invoice is handled by finance, and neither of them has file SLA credit requests on a list. By the time the month closes and someone notices the bill, the window has often already passed. Assign the task to a person and attach it to the incident process rather than the billing cycle, because the incident is the trigger and the billing cycle is too late.
The exclusions do similar work. Scheduled maintenance with adequate notice is almost always excluded, as are failures caused by your own configuration, by exceeding documented limits, or by circumstances outside the provider's control. Subtract those before deciding whether you have a claim.
Why independent evidence decides it
When you file a claim, you are disputing a measurement with the party that took it. That is the whole difficulty, and it is why evidence quality determines outcomes.
Provider incident timelines are frequently narrower than customer experience. They tend to start when the provider confirmed the issue and end when they believed it resolved, which excludes the period when the service was failing but unacknowledged, and often excludes the tail while things recovered. If your only evidence is their status page, you are accepting their number by default.
Independent, timestamped monitoring from outside the provider's network changes the conversation. It gives you a start time earlier than their acknowledgement, an end time reflecting when the service was actually usable again, and per-location results showing regional failures their global summary may have averaged away. That is objective data they cannot easily dispute, and it is difficult to produce after the fact, which is the point: the monitoring has to already be running.
It is also worth being realistic about proportion. For a small monthly spend, a 10% credit may not justify the effort. The claim is usually worth making when spend is substantial, when the outage was long, or when you want the breach formally on record for a renewal conversation. That last reason is frequently the strongest one.
Common mistakes in claiming SLA credits
Assuming the credit arrives automatically. It almost never does. Providers are contractually obliged to pay only when you claim, and unclaimed credits stay unpaid.
Missing the filing window. The most common failure. Windows of 30 to 60 days are typical and start from the incident or the billing cycle, not from when you noticed. Attach the task to the incident process.
Relying on the provider's timeline as evidence. It generally starts at acknowledgement rather than onset and ends at their internal resolution. Independent monitoring produces earlier start times and more honest durations.
Not subtracting the exclusions before calculating. Scheduled maintenance, your own misconfiguration, and usage beyond documented limits are typically excluded. Calculating without removing them produces a claim that gets rejected on arithmetic.
Filing through the wrong channel. Providers specify a route, and a request sent as a normal support ticket or by email to an account manager may not count as filed. Follow the documented procedure exactly.
FAQ
What is an SLA credit?
A contractual remedy where a provider credits back a percentage of your fees when availability falls below the committed level for a billing period. It is applied to future invoices rather than refunded, it is capped at a proportion of your spend, and it is usually stated as your sole remedy.
Are SLA credits automatic?
Almost never. Nearly all agreements require you to submit a claim within a defined window, with supporting evidence, through a specified channel. Missing any of those forfeits the credit regardless of how severe the outage was.
How long do I have to claim an SLA credit?
It varies by provider and is usually between 30 and 60 days. AWS requires requests by the end of the second billing cycle after the incident, Google Cloud requires notification within 60 days with supporting log files, and Microsoft 365 typically requires submission within 30 days following the month.
What evidence do I need for an SLA credit claim?
Timestamps for when unavailability started and ended, what failed, and ideally independent measurement from outside the provider's network. Provider timelines tend to start at acknowledgement rather than onset, so third-party monitoring data usually produces a longer and more accurate duration.
Closing thought
The most useful thing to understand about SLA credits is what they are for. They are not compensation, because they are capped at a fraction of your bill rather than any measure of your loss. They are an accountability mechanism: a contractual acknowledgement that availability was promised and missed, which is why the strongest reason to claim one is often not the money but having the breach formally recorded before your next renewal conversation.
Whichever reason applies, the claim rests on evidence you had to be collecting beforehand. Odown checks from seventeen global locations at intervals down to one minute on every plan, including the twelve dollar tier, which produces exactly the timestamped, independent, per-region record a credit claim depends on. Monitoring the services you buy, not only the ones you run, is what turns an outage you remember into an outage you can document.
