SLA in Software: What Goes In One and What It Costs You

Short answer: an SLA in software is a promise about availability and support with a price tag attached. It has six moving parts, and the one that decides what it costs you is not the uptime percentage everybody argues about. It is the definition of downtime sitting underneath it.

I see a lot of SLAs. Most of the vendor-side pain in them does not come from the number on the front page. It comes from three or four sentences further down that nobody read carefully, usually because the negotiation burned all its energy fighting over whether the answer was 99.9% or 99.95%. So here is what is actually in a software SLA, and where each piece bites.

The Six Parts of a Software SLA.

Strip away the formatting and every SLA in software is the same six things:

• The availability target. The percentage, measured over some period.
• The measurement method. What counts as “down,” who measures it, and over what window.
• The exclusions. Everything that does not count against the number.
• Support commitments. Response times, usually by severity level.
• The remedy. What the customer gets when you miss. Almost always service credits.
• The escalation. What happens when you miss repeatedly. This is the dangerous one.

Get the first five roughly right and the sixth one wrong and you have handed your customer a termination right. I have seen that happen more than once.

Know What the Number Actually Costs.

Vendors agree to uptime targets without doing the arithmetic. Do the arithmetic. Here is what each commitment buys the customer in allowed downtime, on a 30-day month:

• 99%. 7 hours 12 minutes a month. Just over 3.5 days a year.
• 99.5%. 3 hours 36 minutes a month.
• 99.9% (three nines). 43 minutes a month. About 8 hours 45 minutes a year.
• 99.95%. 21 minutes 36 seconds a month.
• 99.99% (four nines). 4 minutes 19 seconds a month, and under an hour for the entire year.

Look hard at that last one. Four nines means a single bad deploy, one cloud provider incident, or one certificate expiry can blow your annual budget in an afternoon. If your infrastructure cannot support it and your monitoring cannot prove it, do not sign up for it. The gap between 99.9% and 99.99% is not a rounding difference in a negotiation. It is roughly a hundredfold difference in operational discipline.

How You Measure Downtime Is the Real Fight.

This is the sentence that decides everything, and it is the one that gets the least attention. Some questions worth settling in writing before you agree to any number:

Is the service “down” only when it is fully unavailable, or also when it is degraded? Degraded-performance clauses are where good SLAs go to die, because “slow” is a matter of opinion and your customer’s opinion will be the generous one. Who measures, you or the customer? Your monitoring should be the system of record; a customer measuring from a single office on a bad ISP will produce numbers you cannot reproduce. Is it measured per feature or across the whole service? Per-feature measurement means one broken report breaks your SLA. And what is the window? Monthly resets the clock twelve times a year; annual measurement smooths out a bad month but means one catastrophic outage taints four quarters.

My default: full unavailability only, measured by vendor monitoring, across the service as a whole, calculated monthly. Every step away from that costs you real money, so trade those steps deliberately instead of conceding them in a redline pass.

Exclusions Make the Number Honest.

The exclusions are not a loophole, they are what makes the percentage meaningful. The standard set: scheduled maintenance inside a stated window with advance notice; emergency maintenance; force majeure; anything caused by the customer’s own systems, network, or misuse; anything caused by third-party services outside your control; and suspension for non-payment or breach.

The one buyers push back on hardest is third-party dependency, and I understand why (they do not care whose fault it is, they just want the software working). But if you run on AWS or Azure, you cannot responsibly promise better availability than your own provider gives you. Say so plainly. In my experience that argument lands, because it is obviously true and it is not a lawyer’s trick.

Commit to Respond. Never to Resolve.

Support commitments belong in the SLA and they are usually the easiest part to give, with one hard rule: commit to response times, not resolution times. You control how fast you pick up the phone. You do not control how long a hard bug takes to fix, and a resolution commitment on a Severity 1 issue is an open-ended promise you cannot keep on a bad day.

A workable structure is severity tiers with a response commitment on each, plus a promise of continuous effort and regular status updates on the highest tier. That gives the customer what they actually want (someone is on it and I will hear from them) without promising an outcome you cannot control.

Service Credits, and Why They Should Be the Only Remedy.

The remedy for a miss should be a service credit against future fees, expressed as a percentage that steps up as the miss gets worse. Three rules make that safe for you:

• Make credits the sole and exclusive remedy. Without this sentence a customer can take the credit and still sue for the downtime.
• Cap the monthly total. Something in the range of 10% to 30% of that month’s fees is normal. Uncapped credits are just a discount schedule written by your worst month.
• Count credits against your liability cap. Credits that sit outside the limitation of liability are exposure you never priced.

Also make the customer claim the credit, in writing, within a stated window. Automatic credits mean your finance team is reconciling something nobody asked for.

Where Vendors Give Away Too Much.

Three recurring mistakes, in rough order of how much they cost:

First, a termination right for chronic failure with no floor. “Customer may terminate if Vendor fails to meet the SLA” sounds reasonable and is enormous. Define chronic (say, three consecutive months below target), give notice and a cure window, and make termination plus a pro-rata refund the entire remedy. Second, carving SLA failures out of the liability cap. Never do this. An availability miss is a service-quality issue; it is not a reason to expose the whole company. Third, agreeing to a number you cannot measure. If you cannot produce a report proving you hit 99.9%, you have not agreed to an SLA, you have agreed to whatever your customer’s dashboard says at renewal time.

And a fourth, quieter one: putting all of this in the signed contract in the first place. There is a strong argument for keeping the metrics on a public page your contract points at, so you update one page instead of every executed agreement. That is a whole topic of its own, and I wrote it up separately in where your SaaS SLA should actually live.

Frequently Asked Questions.

What does SLA stand for in software? Service Level Agreement. It is the part of a software or SaaS contract that sets availability and support commitments and says what the customer gets if you miss them.

What is a good uptime SLA for software? 99.9% is the common enterprise expectation for SaaS. 99.5% is defensible for smaller or non-critical products. 99.99% should only be offered if your architecture and monitoring genuinely support it, because it allows about four minutes of downtime a month.

Is an SLA legally binding? Yes, when it is part of the contract. That is exactly why the remedy language matters: a binding promise with an uncapped remedy is a very different risk from a binding promise whose consequence is a capped service credit.

Should the SLA be in the main agreement or an exhibit? An exhibit or a referenced policy, in my view. It keeps the operational detail out of the signed body and makes it far easier to update as the service changes.

Can I change my SLA later? Only if you reserved the right to. If your SLA lives on a referenced page, say you may update it on notice and that you will not reduce the target during the customer’s current term.

None of this is complicated, but it is detailed, and the details are where the money is. Do the arithmetic before you agree to the number. I hope this helps.

Resources:

• SaaS SLA: Put It on Your Trust Site, Not in the Contract
• Limitation of Liability Clause: The One Word That Cost a Vendor $1.88 Million
• Contract or Policy: Which One Does a Software Company Need, and When?
• Acceptance vs. Completion Criteria in a Software SOW

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.