Read enough AI vendor contracts and a pattern shows up: the service-level agreement section is the one written to be skimmed. It has the reassuring nouns — "uptime," "guarantee," "commitment" — sitting in a paragraph that, read closely, commits the vendor to almost nothing. That is not an accident. An SLA is a liability-allocation document first and a promise second, and vendors write the first draft.
None of this is unique to AI vendors. Traditional SaaS SLAs have used these same structures for years. What is different is the stakes: an AI tool making decisions, drafting communications, or touching customer data has more ways to cause a real loss than a tool that just needs to stay online, and most AI vendor contracts have an SLA that only ever talks about the online part.
What the language usually does
- Uptime guarantees typically exclude "scheduled maintenance" from the downtime calculation — and a meaningful share of vendor contracts set no cap on how much maintenance time can be excluded and no minimum notice period.
- Where credits are capped, the common range is 10–30% of the affected month's fees, with the credit as your sole and exclusive remedy — so even a multi-day outage produces a small bill adjustment, not compensation for the loss it caused.
- Almost no standard AI vendor SLA covers output quality at all. The uptime number can hold at 99.9% while the model is measurably less accurate than what you evaluated at signing, and the SLA is silent on that because it was never written to speak to it.
- The features doing the actual "AI" work are frequently shipped under a separate "beta" or "as-is" label inside the same contract — carved out of the very warranties and remedies the rest of the agreement appears to offer.
- Force majeure clauses in some contracts reach well past acts of God — into third-party infrastructure failures, "equipment breakdown," or vaguely defined "circumstances beyond reasonable control" that can describe a routine outage.
01Why the reassuring paragraph reassures nobody who reads it twice
An SLA exists to do one job for the vendor: define, in advance, exactly how little a bad day is allowed to cost them. Every clause below is a version of that same move — narrow what counts as a failure, cap what a failure is worth, and name the one remedy you get so you cannot ask for another.
That is a legitimate thing for a vendor to want. It is also legitimate for you to read the same paragraph and notice what it does not say, because the gap between "sounds like a guarantee" and "is a guarantee" is exactly where the words live.
02"Excludes scheduled maintenance" — with no cap and no notice
A 99.9% uptime commitment sounds precise. It usually is precise — about the wrong thing. Most uptime SLAs calculate that percentage only against time the vendor did not designate as "scheduled maintenance," "planned maintenance," or "excluded downtime." Reasonable on its face: nobody expects a guarantee to cover a planned upgrade window announced in advance.
The red flag is not that maintenance is excluded. It is what is missing around the exclusion: no cap on how many hours per month can be called maintenance, no minimum advance-notice requirement, and no definition tight enough to stop "maintenance" from also covering an unplanned fix once it is already underway. A vendor free to declare unlimited hours of unannounced "maintenance" has an uptime number that is true and meaningless at the same time.
The three-minute version
Open the SLA and search for "maintenance." If there is no number next to it — a cap in hours per month, a minimum notice period in days — that clause has no edge. It can absorb as much downtime as the vendor needs it to.
03The remedy is a credit, it is capped, and it is the only thing you get
Even when an SLA is clearly breached, look at what happens next. In the overwhelming majority of SaaS and AI vendor contracts, the remedy is a service credit — a percentage knocked off a future invoice — and that credit is explicitly named the customer's sole and exclusive remedy. That phrase matters more than the percentage next to it: it is the clause that closes the door on suing for the actual cost of the outage.
The percentage itself is usually modest and tiered by severity, commonly landing in the 10–30% range of the fees for the affected billing period, with an overall cap — often 100% of one month's fees, sometimes lower. Do the arithmetic on what that means: a three-day outage that costs you real revenue or a missed deadline may earn you a credit worth a fraction of what you paid that month, applied against a bill you have to keep paying to use.
| SLA clause | What it sounds like | What it actually commits the vendor to |
|---|---|---|
| "99.9% uptime guarantee" | The service will almost always be available | Available outside of an uncapped, loosely defined "scheduled maintenance" window — which may not be small. |
| "Service credits are your exclusive remedy" | You will be compensated if we fail you | A capped percentage off a future bill, and a waiver of the right to claim anything more — including the actual cost of the outage. |
| "AI features provided on an as-is / beta basis" | A standard disclaimer, boilerplate | The features doing the actual work are carved out of the warranties and remedies elsewhere in the same contract. |
| No mention of output accuracy anywhere in the SLA | Not applicable — SLAs are about uptime | The model can be 100% available and simultaneously producing worse outputs than what you evaluated, with no SLA breach and no remedy. |
| "Force majeure includes circumstances beyond our reasonable control" | Standard protection for genuine disasters | Broad enough in some contracts to cover a subprocessor's routine outage or an "equipment failure" — ordinary operating risk, not a disaster. |
Illustrative patterns drawn from published SLA and contract guidance, not any single named vendor's wording. Your actual exposure depends entirely on the specific contract in front of you — this table is a reading guide, not a substitute for reading it.
04The clause that almost never exists: an SLA on the AI itself
Here is the gap that is specific to AI vendors and does not show up in a traditional SaaS SLA. Uptime SLAs measure whether the servers respond. They say nothing about whether what comes back is any good. A vendor can update, fine-tune, or swap the underlying model behind an API at any time, and your uptime metric will not move even if the outputs you now receive are meaningfully worse than the ones you evaluated when you signed.
Almost no standard AI vendor SLA addresses this. There is no equivalent of "99.9% uptime" for accuracy, consistency, or output quality, because those are harder to define and measure than whether a server answered a request. That asymmetry is worth naming plainly: the metric the SLA protects is the one that is easy for the vendor to guarantee, not the one you actually depend on. See also the pattern in why the same prompt gives different answers on different days — that inconsistency is, structurally, exactly what no SLA in most AI contracts is written to cover.
05"Beta" and "as-is" language, sitting inside a contract that otherwise sounds solid
Watch for a second contract living inside the first one. The master agreement offers warranties, an SLA, indemnification — the normal architecture of a vendor contract. Then a separate clause, sometimes in a schedule or an "AI features" addendum, disclaims all of that for the specific features doing the AI work: provided "as-is," "as-available," or "in beta," with no warranty of fitness for any purpose and no liability for output.
The practical effect is that the parts of the agreement that read as protective may not apply to the part of the product you are actually buying. A generic SaaS "as-is" disclaimer was written for software that either runs or does not. Applied to a generative feature, it can mean the vendor has disclaimed responsibility for the one thing — the quality and reliability of what the AI produces — that was the reason you signed.
06Force majeure broad enough to cover a bad Tuesday
Force majeure clauses exist for genuine disasters — war, natural disaster, government action that makes performance impossible. That is a reasonable, standard protection. The version worth flagging is one written broadly enough to also cover routine operating risk: a subprocessor's infrastructure outage, vaguely defined "equipment breakdown," or a catch-all like "any circumstance beyond the vendor's reasonable control" with no narrower list underneath it.
The tell is whether the clause distinguishes between events genuinely outside the vendor's control and events that are, in substance, the vendor's own infrastructure or vendor-selection choices going wrong. A cloud region outage at the vendor's own hosting provider is arguably a business risk the vendor chose when it picked that provider — not force majeure in the sense the clause is supposed to mean.
07What to actually check before you sign
- A numeric cap on scheduled maintenance, stated in hours per month, plus a minimum advance-notice period — not just the word "scheduled."
- Tiered credits that scale with the severity and duration of the breach, not a single flat percentage regardless of whether the outage lasted an hour or three days.
- A stated overall cap on the credit — know the number, not just that a cap exists — and whether "sole and exclusive remedy" language forecloses anything beyond it.
- A termination right for chronic or repeated breaches, separate from the credit — the ability to leave without penalty if the vendor keeps missing the same SLA, not just a bill adjustment each time.
- Whether any commitment covers output quality or accuracy, not only uptime — and if the vendor's marketing makes specific capability claims, ask for those reflected as measurable terms in the contract, not left in a sales deck.
- Whether AI-specific features carry a separate "beta" or "as-is" carve-out that narrows the warranties in the rest of the agreement — find that clause and read it against the feature you are actually buying.
- The exact wording of the force majeure clause, and whether it is limited to genuine disasters or reaches into "circumstances beyond reasonable control" broad enough to excuse routine operational failures.
- A short claim window is itself a red flag if it is very short and unforgiving — some contracts require you to notice, document, and claim an SLA breach within days or forfeit the credit entirely. Know the window and who inside your business is responsible for watching for it.
This list is a companion to, not a replacement for, the broader contract checklist in what to check in an AI vendor contract — the SLA is one section of a longer document, and data rights, liability caps, and pricing terms elsewhere in the same contract deserve the same read.
08The honest summary
None of this means walk away from AI vendors, or that every SLA is written in bad faith. It means the SLA section is the part of the contract most likely to be read as a promise when it was drafted as a liability limit, and the gap between those two readings is where a small business absorbs a cost it did not see coming. The fix costs nothing but attention: find the maintenance cap, find the credit cap, find whether output quality is mentioned anywhere, find the beta carve-out, and read force majeure for how far it reaches. Ask for the ones that are missing before you sign, not after the outage that would have needed them.
09Common questions
What is a service-level agreement supposed to guarantee?
In most vendor contracts, an SLA guarantees a measurable operational commitment — typically uptime, expressed as a percentage like 99.9%, along with the remedy if the vendor misses it. It is a liability-allocation document as much as a promise: it defines in advance exactly what counts as a failure and exactly how little that failure is allowed to cost the vendor. Reading it closely, rather than skimming the percentage, is how you find out which one it actually is.
Why does 'excludes scheduled maintenance' matter so much?
Because uptime is calculated only against time the vendor has not designated as maintenance, and many contracts put no cap on how much time can be excluded and no requirement to give advance notice. A vendor with unlimited, unannounced 'maintenance' can hold a headline uptime number that is technically true while your actual experience of availability is much worse. Check for a stated cap in hours per month and a minimum notice period — their absence is the red flag, not the exclusion itself.
If a vendor breaches its SLA, what do I actually get?
Almost always a service credit — a percentage off a future invoice, commonly in the 10 to 30 percent range of the affected month's fees, capped overall and named your sole and exclusive remedy. That last phrase is the important part: it typically forecloses claiming the actual cost the outage caused you. A multi-day outage can produce a credit worth a small fraction of the real loss, applied against a bill you still have to keep paying.
Why don't SLAs cover whether the AI's output is any good?
Because uptime SLAs measure whether a server responds, not whether the response is accurate, consistent, or as good as what you evaluated when you signed. Almost no standard AI vendor SLA sets any commitment on output quality, so a vendor can update or fine-tune the underlying model at any time and your uptime metric will not move even if the results genuinely get worse. This is the clearest gap between what an AI vendor's SLA covers and what you are actually depending on.
What does an 'as-is' or 'beta' carve-out do inside an otherwise normal contract?
It can quietly remove the warranties and remedies that appear to apply elsewhere in the agreement, specifically for the AI features doing the work you are paying for. Watch for a separate clause or addendum that disclaims fitness for any purpose and liability for output on the AI-specific parts of the product, even while the rest of the contract reads as protective. Find that clause and check it against the exact feature you plan to rely on before you sign.
Is a broad force majeure clause always a problem?
Not by itself — force majeure exists for genuine reasons, like natural disasters or government action that makes performance impossible, and that core protection is standard and reasonable. The red flag is language broad enough to also excuse routine operating risk: a subprocessor's ordinary outage, vaguely defined 'equipment breakdown,' or a catch-all for 'circumstances beyond reasonable control' with no narrower list underneath. Read the clause for whether it stays limited to genuine disasters or reaches into a vendor's own infrastructure choices going wrong.
What should I actually ask a vendor to change before signing?
Ask for a numeric cap on scheduled maintenance with minimum notice, tiered credits that scale with the severity and length of an outage, a stated overall credit cap, a termination right for repeated breaches rather than only a credit each time, and — if the vendor makes specific capability claims — some measurable commitment on output quality rather than uptime alone. Not every vendor will move on all of these, but asking in writing establishes what you were told before you signed, which matters if a dispute follows.
Does this apply to small AI tools, or only large enterprise contracts?
It applies at any size, though smaller vendors are often less willing to negotiate specific terms than enterprise sales teams are. Even where you cannot change the contract, reading it for these specific gaps tells you what you are actually exposed to — the maintenance cap, the credit cap, whether output quality is covered, and how broad force majeure reaches — so a bad outage is not the first time you learn what the SLA actually promised.
Send us the SLA section
Paste us the service-level and limitation-of-liability sections from a contract you are about to sign. We will tell you which of the gaps above are present, in plain language, before you commit to it. We do not sell AI tools, so there is nothing at the end of this for us to sell you.
Ask for an SLA checkSources, read 18 September 2026: published legal and contract-guidance analysis on SLA structure, uptime exclusions and scheduled-maintenance clauses, service-credit caps and sole-exclusive-remedy language, force majeure scope in SaaS and technology contracts, and the gap between AI vendor uptime SLAs and output-quality commitments, including guidance on "as-is" and beta disclaimers specific to generative AI features. This is not legal advice. SLA and liability terms vary significantly by vendor and are frequently negotiable at the contract stage; nothing here should be relied on in place of a qualified reading of your own contract. Related: Six Clauses to Check Before You Sign and Why Your Software Bill Stopped Being Predictable.
Hero image from Unsplash, used under the Unsplash License.