An SLA service credit is a contractual remedy where a vendor credits back a percentage of your fee when measured uptime falls below the promised SLA tier for a billing period. It is usually a capped credit you have to request against a future invoice, not an automatic cash refund. Miss the request window or the paperwork, and you get nothing, even if the outage was real.
Service credits sit in the fine print of most cloud and SaaS contracts, unread until the day the service goes down. They sound like protection, and they are, but a narrow kind. Knowing how they work, and how to prove you are owed one, is the difference between getting money back and writing an angry email that goes nowhere.
What is an SLA service credit?
A service level agreement (SLA) is the promise: the vendor commits to a target, say 99.9% uptime in a calendar month. The service credit is what happens when they break that promise. Instead of the vendor owing you damages in court, the contract pre-agrees a fixed remedy: a percentage of your monthly fee, credited back. It is the "sorry we were down" line item, and it is the only remedy most standard SLAs offer.
The key word is credit. You are not getting a wire transfer or a refund to your card. You get a reduction applied to a later bill, which is why the vendor's billing side treats it as an adjustment rather than a payout. It also helps to separate the promise, the target, and the measurement, covered in the breakdown of SLA, SLO and SLI.
How the credit percentage scales with the miss
Service credits are almost always tiered. The worse the miss, the bigger the credit. The exact numbers vary by vendor, but the shape is remarkably consistent across the big cloud providers. Here is a typical, illustrative structure, close to the style used in AWS, Google Cloud, and Azure SLAs. Treat these as an example of how tiers are built, not as any one vendor's exact figures.
| Measured monthly uptime | Typical service credit | What it means |
|---|---|---|
| At or above the SLA target (e.g. 99.9%) | 0% | Promise kept, no credit owed |
| 99.0% to under 99.9% | 10% | A modest miss, a token credit |
| 95.0% to under 99.0% | 25% | A real outage, roughly a day of trouble |
| Below 95.0% | 50% to 100% | Severe: over a day and a half down in a month |
To put those percentages in context: 99.9% uptime allows about 43 minutes of downtime a month, while 95.0% allows roughly 36 hours. So the jump from a 10% credit to a 25% credit maps to a genuinely bad month. The piece on a good uptime percentage lays out the minutes-per-nine for each level.
Notice what the tiers do not do: they do not scale with your loss. A 25% credit on a $200 monthly bill is $50, whether the outage cost you nothing or cost you a five-figure sales day. The credit is tied to what you pay the vendor, never to what the outage did to you.
How service credits are usually claimed
This is where most credits quietly evaporate. The typical SLA does not apply credits automatically. You have to notice the miss, prove it, and file a request, and each of those steps has a catch.
- You must request it, in writing, within a window. Thirty days after the end of the affected billing period is common. Miss the window and the claim is void, no matter how bad the outage was.
- You often have to supply your own evidence. Many SLAs ask the customer to include logs, timestamps, or request IDs showing the errors. The vendor is not going to build your case for you.
- The credit is capped. The ceiling is nearly always the fee for the affected service in that month. You cannot get back more than you paid, even at a 100% tier.
- Exclusions carve out a lot. Scheduled maintenance, problems caused by your own code or configuration, third-party failures outside the vendor's control, and force majeure are typically excluded from the uptime calculation entirely.
That last point is the sharp one. If a vendor announces a maintenance window, downtime inside it usually does not count against the SLA. Once you subtract every excluded minute, the measured number can be a lot friendlier to the vendor than your experience of the day.
On the vendor's side, once a valid claim is approved, the credit is applied against the customer's next invoice, which the billing team then has to track and reconcile. From the customer's chair, the money shows up as a smaller bill next month, not as cash today.
alertping
Know the minute your SLA breaks
AlertPing checks as fast as every 30 seconds from three regions and keeps a rolling uptime history, so you have timestamped proof of every outage when it is time to file a credit claim. SMS, email, Slack, and webhook alerts on every plan.
Why service credits are a weak remedy
Read enough SLAs and a pattern shows up: the service credit is written to protect the vendor as much as the customer. It caps the vendor's exposure at a slice of one month's fee, and in most contracts it is named as your sole and exclusive remedy, meaning you agree not to sue for more. That is a fair trade for predictability, but it is a poor match for real business loss.
Consider the math. A checkout outage during a holiday sale might cost an ecommerce store tens of thousands in lost orders and support cost. If that store pays $500 a month for the platform, the largest possible credit is $500, and the likely credit is $50 to $125. The credit was never designed to cover the loss. It was designed to acknowledge the miss and keep the relationship going. Treat it as a goodwill gesture with a formula, not as insurance.
You can negotiate stronger terms, higher caps, faster escalation, or credits that count partial outages of specific components, but those are enterprise contract items, not the default. For most buyers, the practical move is to assume the credit will be small and focus on avoiding the outage and proving it cleanly when it happens.
How to measure uptime so you know if you are owed a credit
You cannot claim a credit you cannot prove. The vendor's own status page is one record, but it is the record written by the party that owes you money, and vendors have been known to under-report. Your leverage comes from an independent measurement of your own.
That means running third-party SLA monitoring against the service you depend on: checks on a tight interval, from more than one region, so a single flaky path does not create a false outage in your own logs. When a check fails, you get a timestamp. String those together across a billing period and you have the exact downtime figure the SLA turns on, in your records, not the vendor's.
Publishing that measurement as uptime history on a status page does double duty. It gives you a dated, public record to attach to a credit request, and if you are the vendor, it is the receipt that shows customers you are holding the SLA. Either way, the credit conversation goes better when both sides are looking at real measured minutes instead of arguing from memory.
Are SLA service credits automatic?
Almost never. Most SLAs require the customer to submit a written claim, often within 30 days of the affected billing period, sometimes with supporting logs or request IDs. If you do not notice the miss and file in time, the credit is forfeited. A handful of vendors auto-apply credits, but assume yours does not unless the contract says otherwise.
How do you calculate a service credit?
Take your measured uptime for the billing period, find which tier it lands in on the vendor's SLA table, and apply that credit percentage to the fee for the affected service that month. Example: a 25% tier on a $400 monthly fee yields a $100 credit, capped at the monthly fee. Excluded minutes, like scheduled maintenance, do not count toward the miss.