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 two 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.
Service credit earn back, and what a capped credit regime means
Two clauses decide how much a service credit is actually worth, and neither of them appears in the headline percentage. The first is the cap. The second is earn back. Read both before you sign, because together they can take a 100% credit tier down to a number you would not have negotiated for.
A capped service credit regime sets a ceiling on how much of a period's fees can be returned as credits, no matter how many targets were missed. Public cloud contracts usually cap at 100% of the monthly charge for the affected service, which sounds generous until you notice it is scoped to that one service rather than to the platform, and that it is a credit against future invoices rather than money. Enterprise outsourcing contracts more often set an "at risk" amount instead: a defined share of the monthly charge, commonly a low double-digit percentage, which is the total pool that all service levels together can draw from in any month. Once the pool is exhausted, further misses in the same month cost the supplier nothing.
Earn back, sometimes written earnback, is the clause that lets a supplier win credits back after they have been assessed. The usual mechanism is consecutive performance: the supplier recovers a credit that was already accrued if it meets or exceeds the same service level for a defined run of following periods, typically three to six months. It is standard in large IT outsourcing and managed service master agreements and rare in off-the-shelf SaaS terms, so which document you are reading tells you most of what you need to know about whether it applies.
| Clause | What it does | Where you usually see it | What to check |
|---|---|---|---|
| Credit cap | Limits credits to a maximum share of the period's fees | Public cloud and standard SaaS terms | Whether the cap is scoped to one service or the whole account |
| At-risk amount | Defines one pool that all service levels draw credits from | Outsourcing and managed service agreements | How the pool is allocated across service levels, and whether it resets monthly |
| Earn back | Returns accrued credits after a run of compliant periods | Enterprise MSAs, rarely in SaaS terms | How many consecutive periods, and whether earn back applies to repeat misses |
| Credit versus deduction | Decides whether you get a future credit or an invoice reduction | Both | Whether an unused credit survives non-renewal, which it usually does not |
| Sole remedy | Makes the credit your only recourse for the miss | Almost every contract of either kind | Whether a chronic-failure clause lets you terminate instead |
Three practical points follow. Earn back only bites if the supplier can prove sustained compliance, and proof means measurement, which is usually the supplier's own measurement unless you brought your own. A capped regime makes the cap, not the tier table, the number worth negotiating, because a 100% tier under a 10% at-risk pool is a 10% remedy. And a credit that expires at non-renewal is worth nothing to a customer who is leaving, which is precisely the customer a bad outage creates.
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. The arithmetic that turns those timestamps into a claimable number is covered step by step in how to calculate uptime percentage.
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. That is the practical argument for website down alerts that reach a human the same minute: the claim window starts whether or not anyone was watching. 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.