What Is a Service Level Agreement (SLA)?

Your sales deck says 99.9% uptime. Your first real enterprise prospect just asked you to put that number in the contract, with money attached to it if you miss.

Those are two very different promises. The first is marketing. The second is a commitment you can be held to, and the gap between them is where a lot of early-stage companies get hurt.

What Founders Need to Know

A Service Level Agreement (SLA) is the part of your customer contract that promises a measurable standard of performance and says what happens if you fall short. It usually lives as an exhibit or an addendum rather than in the body of the agreement, which is exactly why it often gets signed without anyone reading it closely.

Most SLAs are built from four moving parts. The service level is the promise itself, typically expressed as an uptime percentage. The measurement window defines the period over which that percentage is calculated, which is far more consequential than founders expect: 99.9% measured monthly allows roughly 43 minutes of downtime per month, while the same number measured annually allows a single outage of nearly nine hours. The service credit is the remedy, usually a percentage of fees refunded or applied to the next invoice. And the exclusions carve out downtime that does not count against you, commonly scheduled maintenance, customer-caused issues, and third-party infrastructure failures.

One clause deserves particular attention. An SLA that states service credits are the customer’s sole and exclusive remedy attempts to cap your exposure for downtime at the credit amount. Without that language, a customer may argue they can claim service credits and separately pursue damages for breach. Whether that argument succeeds can depend on how the SLA interacts with the limitation of liability provision elsewhere in the contract, and on applicable law.

It is worth being clear about what an SLA is not. It is not a description of how your system currently performs. It is a forward-looking promise, and it can be enforced whether or not your infrastructure is ready to keep it.

What This Looks Like in Practice

Imagine your startup is a workflow automation platform, 14 months old, running on a single cloud region. Your largest prospect sends over a redlined agreement with an SLA exhibit requesting 99.95% monthly uptime, a 25% service credit for any month below that, and a termination right if you miss three months in any rolling 12.

The number looks close enough to what you already tell people, so your team accepts it to keep the deal moving. Nine months later your cloud provider has a regional incident. You are down for six hours. That is a single event, and it puts you below 99.95% for the month.

Now the details start to matter. Your exclusions list covers scheduled maintenance but says nothing about third-party infrastructure, so the outage counts against you. Your credit is 25% of monthly fees, which stings but is survivable. The harder problem is the termination trigger, because two more incidents in the following 11 months would let your largest customer walk. Suddenly a routine infrastructure decision, whether to add a second region, is not an engineering question anymore. It is a question about whether you keep your anchor customer.

Nothing here required bad faith or bad drafting by the customer. It required only that nobody on your side ran the arithmetic before signing.

Three Common Founder Mistakes

• Promising a number you cannot measure. If you have no monitoring that produces a defensible uptime figure, you cannot prove you met your SLA and you cannot efficiently rebut a customer who claims you did not. Commit to a standard you can actually instrument.
• Leaving out the exclusive-remedy language. Service credits are meant to be a ceiling on downtime exposure, not a floor. If the SLA does not say credits are the sole and exclusive remedy for missed service levels, you may have created a payment obligation without capping the underlying claim.
• Copying an SLA from a company that is not you. The SLAs published by major cloud providers are written for businesses with global redundancy, dedicated reliability teams, and enormous customer volume. Adopting their numbers without their architecture means adopting their promises without their ability to keep them.

10-Minute Founder Self-Check

• What uptime number, if any, appears in our sales materials, website, or proposals right now?
• Do we have monitoring that could produce a defensible uptime figure for last month?
• Is our measurement window monthly, quarterly, or annual, and do we know what each allows in actual minutes?
• Does our SLA exclude scheduled maintenance, and have we defined how much notice scheduled maintenance requires?
• Does our SLA exclude failures of the cloud infrastructure we do not control?
• Are service credits stated as the sole and exclusive remedy for missed service levels?
• Does any customer have a termination right tied to repeated SLA misses, and do we know how close we are to triggering it?
• Do our SLA commitments differ across customers, and does anyone maintain a single list of what we have promised to whom?

What to Do Next

An SLA is one of the few contract terms where the legal question and the engineering question are the same question. Before you commit to a number in writing, it is worth having someone look at the SLA, the limitation of liability clause, and your actual infrastructure together, because those three things either line up or they do not.

Schedule a free 30-minute call with our team to discuss your needs and concerns.  

Book here: Initial Consultation with Primum Law Group – Primum Law Group, PC