SLA penalties vs. service credits: structuring uptime promises you can actually keep

For most MSP contracts, service credits are the safer way to back an uptime promise, and penalties are the version that can bankrupt you on a bad month. A service credit refunds a slice of the monthly fee when you miss the target. A penalty is a separate payment the client can stack on top of everything else, and it is often uncapped. If your SLA uses the word "penalty" where you meant "credit," you may have promised far more than you think.

That one distinction decides whether a four-hour outage costs you $90 or $9,000. The rest comes down to how you write the numbers.

This is general information, not legal advice. I am an MSP operator writing about what to look for, not a lawyer telling you what your contract means. Run any language past your own attorney before it goes in front of a client.

Service credits vs. penalties: what's the actual difference?

A service credit is a pre-agreed remedy. You miss 99.9% uptime in a given month, the client gets, say, 10% of that month's recurring fee back as a credit on the next invoice. The amount is tied to what they paid you. It is capped by definition because you can only credit back so much of a fixed monthly fee.

A penalty is a payment meant to punish, and courts in a lot of jurisdictions treat penalties differently from a genuine pre-estimate of loss. More to the point for you: penalty clauses are often written as a flat dollar figure or a per-hour rate that keeps climbing. "$500 per hour of downtime beyond the SLA" sounds small until a weekend firewall failure runs 14 hours and you owe $7,000 on a $1,200-a-month account.

The practical rule I use: credits come out of what the client already pays you. Penalties can exceed it. One is a discount, the other is a liability.

Then there's consequential damages, the client's lost revenue, lost profit, the deal they say they missed because email was down. That is the real exposure, and it is usually much larger than any credit. Service credits are supposed to be the client's sole and exclusive remedy so they cannot collect the credit and then sue you for lost business on top of it. If your SLA has credits but no "sole and exclusive remedy" language, you have given away the cap you thought you bought.

The uptime math MSPs promise without checking

Before you write any number, know what the percentage actually costs you in minutes. Allowed downtime per month, roughly:

• 99% = about 7 hours 18 minutes per month
• 99.9% ("three nines") = about 43 minutes per month
• 99.95% = about 21 minutes per month
• 99.99% ("four nines") = about 4 minutes 22 seconds per month

Four nines means total downtime of under five minutes a month. One reboot of a key appliance blows it. A single ISP blip at the client site blows it. If you are reselling a connection you do not control, promising 99.99% is a promise you cannot keep, and you will be writing credits every month.

Most MSPs can stand behind 99.9% for services they fully manage, and that is already a real commitment: 43 minutes a month, every month. Pick the number you can hit on your third-worst month, not your best one.

Scope the promise, or you've promised the internet

The most expensive SLA mistake is not the percentage, it is the scope. "99.9% uptime" with no definition means uptime of everything, including things you do not run.

Spell out exactly what the number covers. Your monitoring agent and managed server, yes. The client's ISP, their landlord's building power, Microsoft 365, the public cloud region, their own on-prem switch they will not let you replace: no.

Carve-outs I want to see in an uptime clause:

• Scheduled maintenance announced 48 hours in advance (and a monthly maintenance window)
• Outages caused by third-party providers you resell but do not control (ISP, upstream cloud, SaaS vendors)
• Force majeure events
• Problems caused by the client's own changes, hardware they refused to replace, or actions by their staff
• Anything outside the specific services listed in the Statement of Work

Without these carve-outs, a Microsoft 365 outage counts against your SLA even though you had nothing to do with it. Microsoft gives you a credit under their SLA, your client wants a credit from you, and the two numbers do not match.

How to cap your exposure in plain clause terms

Three caps do the heavy lifting. If a client asks you to remove all three, that is your signal to raise the price or walk.

1. A per-event / per-month credit cap. Credits for any single month should max out at a set percentage of that month's fee. 10%, 25%, maybe 50% at the extreme. Not 100%, because a month of credits should not mean you worked for free on an account you still had to staff.

2. A sole-and-exclusive-remedy clause. The credit is the only thing the client gets for a missed SLA. This is what blocks the lost-revenue lawsuit.

3. An overall limitation of liability. Total liability capped at the fees paid over the trailing 3, 6, or 12 months, with consequential damages excluded entirely. This sits above the SLA and catches everything else.

Here is the shape of credit language I look for, as an example to discuss with your lawyer, not to copy blind:

If monthly uptime for the Covered Services falls below 99.9%, Client's sole and exclusive remedy is a service credit equal to 10% of that month's recurring fee for each full 0.1% below target, up to a maximum credit of 30% of that month's recurring fee. Client must request the credit in writing within 30 days of the affected month. Credits are applied to a future invoice and are not payable in cash.

Walk through what that clause does. It caps the single-month hit at 30%. It makes the client ask for the credit (a lot of credits never get claimed because no one files the request). It keeps credits as invoice credits, not cash refunds, so you are never cutting a check. And it names "Covered Services," which points back to your scope definition.

The claim window and the request requirement

Two small lines save real money. First, require the client to request the credit in writing within a set window, 30 days is common. No request, no credit. Second, require them to be current on their invoices to claim one. A client who is 60 days late on payment should not be collecting SLA credits.

I have seen MSPs auto-apply credits they were never asked for because their PSA flagged the SLA miss. That is money out the door for an outage the client did not even notice. Make the credit a claim, not an automatic payout.

A quick checklist before you sign

Run any uptime clause through this:

• Does it say "credit" or "penalty"? If "penalty," ask why.
• Is the uptime number one you can hit on a bad month, not a good one?
• Is "uptime" defined by specific Covered Services, or left open?
• Are ISP, SaaS, power, maintenance, and client-caused issues carved out?
• Is there a per-month credit cap (and is it below 100%)?
• Is there "sole and exclusive remedy" language?
• Is there a separate overall limitation-of-liability clause excluding consequential damages?
• Must the client request the credit in writing within a set window?
• Must the client be current on payment to claim?

If more than two of those are missing, the SLA is writing checks your operations may not cash. Fix the language before the outage, because after the outage the client holds all the leverage.

The goal is not to dodge accountability. It is to promise a number you can actually hit and to cap the downside so one bad weekend does not wipe out a quarter of margin on the account.