Skip to main content

Service Level Agreement Clause: Uptime, Exclusions, and Service Credits

Also known as: SLA, uptime, service credits

ByArshita Anand

A service level agreement (SLA) clause sets a measurable performance commitment, usually uptime, defines what counts against it, and says what the customer gets when the vendor misses, almost always a service credit. The number that matters is not the uptime percentage; it is the exclusions that shrink it and whether credits are your only remedy.

Reviewed and corrected on 12 October 2026. This is general information, not legal advice; check the cited statute or opinion before relying on it.

TL;DR

  • An SLA clause has three moving parts: the metric (uptime, response time, resolution time), the exclusions (maintenance, force majeure, customer-caused issues), and the remedy (service credits, usually a percent of fees).
  • "99.9% uptime" sounds strong but allows about 8.8 hours of downtime a year (0.1% of 8,760 hours). 99.99% allows about 53 minutes. Always do the minutes math before you accept a number.
  • The exclusions decide the real availability. Scheduled maintenance, beta features, and third-party outages are commonly excluded, and a broad exclusion list can make a high uptime number meaningless.
  • Service credits are usually a percentage of the monthly fee, tiered by how far the vendor missed, and capped. Published cloud SLAs, read on 12 October 2026, show the range: the AWS EC2 Region-Level SLA (the AWS page is marked "Last Updated: May 25, 2022") credits 10%, 30% or 100% of the bill, Google Compute Engine's tiers are 10%, 25% or 100%, and Google Workspace credits 3, 7 or 15 days of service. The customer must usually request the credit within a set window (30 days for Google Workspace, 60 days for Compute Engine, the end of the second billing cycle for AWS).
  • A costly review miss is "service credits are the sole and exclusive remedy." That language can bar termination and damages for chronic outages. Negotiate a chronic-failure termination right that survives it.

What an SLA clause actually does

An SLA turns a vague promise of reliability into a measured commitment with a defined consequence. It does three things.

1. It defines the metric and how it is measured. Uptime is the common one, but the definition is everything: what counts as "available," who measures it, over what window (monthly is standard), and whether it excludes maintenance. Two vendors can both claim 99.9% and mean very different things.

2. It lists the exclusions. These are the periods that do not count against the SLA: scheduled maintenance, emergency maintenance, force majeure, outages caused by the customer or its third-party tools, and often beta or free features. The longer this list, the lower the real availability the number guarantees.

3. It sets the remedy. Almost always a service credit, calculated as a percentage of the fee for the affected period and tiered by severity. The key question is whether credits are the only remedy or whether the customer keeps the right to terminate and seek damages for repeated failures.

Why it matters: the dollars at stake

Picture a $240,000-a-year SaaS contract ($20,000 a month) with a 99.9% uptime SLA and a tiered credit: 10% of the monthly fee below 99.9%, 25% below 99.0%.

  • A bad month brings the service to 98.5% uptime, roughly 11 hours of downtime. The customer earns a 25% credit, $5,000, against a month where a key system was down for most of a business day.
  • If the credit is the sole and exclusive remedy, the customer's downstream losses (missed customer commitments, staff idle time) are not recoverable, and the customer cannot leave even if this is the third bad month in a row.
  • With a chronic-failure termination right (for example, the SLA is missed three months in any rolling six), the customer can exit for cause and avoid the rest of the term.

Same outage, same SLA. The $5,000 credit is real but small next to the business impact; the right to leave after a pattern of failures is usually worth far more than the credit itself.

Who wants what

Customer / buyerVendor / provider
Uptime targetHigher (99.95% or 99.99%)Lower (99.5% or 99.9%)
ExclusionsNarrow; scheduled maintenance capped and noticedBroad; maintenance, beta, third-party all excluded
MeasurementDefined, vendor reports monthlyVendor measures, customer must request credit
Credit sizeLarger, lower threshold to triggerSmaller, capped at a month's fee
Sole remedyCredits plus termination and damages for chronic failureCredits are the sole and exclusive remedy
Chronic failureTermination for cause after repeated missesNo special exit; rely on the term

The pattern: the customer wants a number it can rely on and a way out if the vendor keeps missing, the vendor wants a predictable, capped credit and no exposure beyond it.

Sample language

A typical SLA clause for a SaaS agreement reads close to this. The 99.9% target, the credit tiers, the 8-hour maintenance cap and the three-in-six chronic-failure test are drafting examples, not market data; published vendor SLAs vary (see the TL;DR):

SERVICE LEVEL AGREEMENT.

(a) Availability. Provider will make the Service available at least 99.9%
of the time during each calendar month (the "Availability Commitment"),
measured as: (Total Minutes in the Month - Excluded Minutes - Downtime) /
(Total Minutes in the Month - Excluded Minutes).

(b) Exclusions. "Excluded Minutes" means downtime caused by: (i) scheduled
maintenance with at least 48 hours' notice, not to exceed [8] hours per
month; (ii) emergency maintenance; (iii) force majeure; (iv) Customer's
acts, equipment, or third-party services; or (v) beta or free features.

(c) Service Credits. If availability falls below the commitment in a month,
Customer is entitled to a credit as a percentage of that month's fee:
   At least 99.0% but below 99.9%: 10%
   At least 95.0% but below 99.0%: 25%
   Below 95.0%: 50%
Credits are capped at 100% of the affected month's fee and must be
requested in writing within thirty (30) days after the end of the month.

(d) Chronic Failure. If Provider fails to meet the Availability Commitment
in three (3) months within any rolling six (6) month period, Customer may
terminate this Agreement for cause and receive a refund of prepaid,
unused fees.

Subsection (d) is the part vendors leave out and customers should add. It converts a string of small credits into a real exit, which is the only remedy that disciplines a vendor with a structurally unreliable product.

The negotiation: standard, fallback, walk-away

Treat the uptime number, the exclusions, and the remedy as three separate trades. The remedy is where most of the value sits.

IssueOpening positionFallback both sides acceptWalk-away
Uptime targetBuyer: 99.99%; Vendor: 99.5%99.9% measured monthlyBelow 99.5%, or "commercially reasonable efforts" with no number
Scheduled maintenanceCapped hours, off-peak, 48h noticeCapped per month, noticed, in a defined windowUnlimited maintenance excluded with no notice
Credit sizeTiered, up to 100% of monthly feeTiered, capped at one month's feeToken credit (under 5%) regardless of severity
Credit processAuto-applied by vendorCustomer requests within 30 daysShort window plus burden on customer to prove downtime
Sole remedyCredits plus damages and terminationCredits as sole remedy for a single miss, plus chronic-failure exitCredits as sole and exclusive remedy, no exit ever

The workhorse compromise: keep service credits as the routine remedy for an ordinary bad month, but carve out a chronic-failure termination right so a pattern of misses lets the customer leave.

Common carve-outs / variations

SLAs vary by what the service does. Frequent variations:

  • Support response and resolution times. Tiered by severity (P1 critical, P2 high, and so on), with separate response and resolution targets. Resolution targets are harder to commit to than response targets.
  • Performance SLAs. Latency or throughput commitments for APIs and infrastructure, not just availability.
  • Disaster recovery. RTO (recovery time objective) and RPO (recovery point objective) commitments after a major incident.
  • Credit stacking. Whether multiple missed metrics in one month stack or are capped together.
  • Earn-back. Some vendors let credits be reduced or earned back by a later period of strong performance; customers should resist or cap this.

A chronic-failure exit, the variation most worth adding, looks like this:

If Provider fails to meet any Service Level in [three] months within any
rolling [six] month period, Customer may terminate the affected Service
(or this Agreement) for cause on [30] days' notice and receive a pro-rata
refund of prepaid, unused fees, in addition to any earned Service Credits.

Jurisdiction and enforceability notes

SLA terms are generally enforced as written between businesses, with a few things to keep in mind:

  • Service credits and the limitation of liability. Credits usually sit alongside a limitation of liability cap and a "sole remedy" provision. In a sale of goods, the Uniform Commercial Code allows a contract to make a remedy exclusive, but "where circumstances cause an exclusive or limited remedy to fail of its essential purpose, remedy may be had as provided in this Act" (UCC § 2-719(2), as published; each state enacts its own version). Consequential damages "may be limited or excluded unless the limitation or exclusion is unconscionable" (§ 2-719(3)). Article 2 governs goods, not SaaS, so whether a court would apply the failure-of-essential-purpose idea to a service-credit remedy turns on the governing state's law. Not verified in our October 2026 review. Check the controlling state's decisions on software and service contracts. Draft the SLA and the liability cap to work together, not against each other.
  • "Commercially reasonable efforts." An SLA with no number, only an efforts standard, gives the customer little to measure, in our drafting judgement. Push for a measurable commitment. (Published vendor SLAs often pair a numeric target with an efforts phrase: the AWS EC2 SLA says AWS "will use commercially reasonable efforts" to meet a stated uptime percentage, and the credit table is tied to that number.)
  • Measurement and burden. If the vendor is the sole measurer and the customer must prove downtime to claim a credit, the practical value of the SLA drops. AWS, for example, requires a claim with request logs "by the end of the second billing cycle after which the incident occurred." Define the metric and require vendor-provided monthly reporting.
  • Penalty concerns. Credits are usually drafted as a price adjustment. A court asked to strike a credit as a penalty would apply the liquidated-damages tests of the governing law: the UCC says a liquidated amount must be "reasonable in the light of the anticipated or actual harm" and that "a term fixing unreasonably large liquidated damages is void as a penalty" (§ 2-718(1)), and California presumes a liquidated damages term in an ordinary commercial contract valid unless the challenger shows it was unreasonable when the contract was made (Cal. Civ. Code § 1671(b)). We did not find a decision applying those tests to SaaS service credits. See liquidated damages.

General information, not legal advice for your deal. Whether a service-credit or sole-remedy clause holds up depends on the governing state and whether the contract is treated as a sale of goods or a service, so check that state's decisions before you rely on it.

Review checklist: red flags to catch

  • The uptime number sounds high but the minutes math allows hours of monthly downtime once you compute it.
  • The exclusions are broad (unlimited maintenance, beta features, all third-party issues), so the real guaranteed availability is far lower than the headline.
  • Scheduled maintenance is uncapped or has no notice requirement or off-peak window.
  • Service credits are a token percentage that does not scale with how badly the vendor missed.
  • The customer must request the credit within a very short window or it is forfeited.
  • "Sole and exclusive remedy" with no chronic-failure termination right.
  • The vendor is the sole measurer with no obligation to report uptime monthly.
  • Earn-back language that erases credits the customer already earned.

How it interacts with other clauses

An SLA does not stand alone. Read it together with:

  • Limitation of liability: the credit can be the only remedy left once the cap and sole-remedy language apply, so the two must be drafted to fit.
  • Termination: the chronic-failure exit is what gives the SLA teeth beyond small credits.
  • Payment terms: credits are usually applied against future invoices, so the billing mechanics have to align.
  • Warranty disclaimer: the SLA is often the only performance promise left after the warranties are disclaimed.
  • Force majeure: force majeure events are typically excluded from SLA downtime, so the two definitions should be consistent.

For the broader workflow, see the in-house contract review playbook.

FAQ

What is a service level agreement clause? It is a contract provision that sets a measurable performance commitment for a service, usually uptime, defines what does not count against it (exclusions), and specifies the remedy when the vendor misses, almost always a service credit as a percentage of the fee.

How much downtime does 99.9% uptime allow? About 8.8 hours per year, or roughly 43 minutes in a 30-day month (0.1% of 43,200 minutes). 99.95% allows about 4.4 hours a year, and 99.99% allows about 53 minutes a year. Always convert the percentage to minutes before accepting the number.

What are service credits? Service credits are the standard SLA remedy: a percentage of the fee for the affected period, refunded or applied to a future invoice when the vendor misses the committed service level. They are usually tiered by severity and capped. The AWS EC2 and Google Compute Engine SLAs, for example, publish tiers that reach 100% of the monthly bill for the worst months, as read on 12 October 2026 (the AWS page is marked "Last Updated: May 25, 2022").

Are service credits the only remedy for an SLA breach? Often the contract says so, with "service credits are the sole and exclusive remedy." That can bar termination and damages even for repeated outages. Customers should negotiate a chronic-failure termination right that survives the sole-remedy language.

What does the exclusions list do in an SLA? Exclusions are periods that do not count against the uptime commitment, such as scheduled maintenance, emergency maintenance, force majeure, and customer-caused issues. A broad exclusions list can make a high headline uptime number much weaker in practice.

What is a chronic failure clause? It is a right to terminate for cause when the vendor misses the SLA repeatedly, for example three months in any rolling six, usually with a refund of prepaid unused fees. It turns a string of small credits into a real exit for a structurally unreliable service.

What is the difference between response time and resolution time? Response time is how quickly the vendor acknowledges or starts work on an issue. Resolution time is how quickly the issue is fixed. Vendors commit to response times more readily than resolution times, since a fix can depend on factors outside their control.

Build US law into your product.
Every US statute, regulation, constitution and executive order via REST, MCP or SQL, with a free open dataset. Built for developers and companies, from small businesses to enterprises.
Updated October 12, 202614 min read

New legal AI guides, weekly.

Arshita Anand

Arshita Anand

Co-Founder & CEO · Attorney

Arshita leads product and strategy at Vaquill AI, the US primary law data API. As an attorney, she decides which law we carry, how each section is sourced and cited, and what legal AI and compliance teams need from the data.

Build US law into your product.

Every US statute, regulation, constitution and executive order via REST, MCP or SQL, with a free open dataset. Built for developers and companies, from small businesses to enterprises.

Cookie preferences

Choose what Vaquill may use on this browser. You can change this at any time from “Cookie settings” in the footer.

Details in the Cookie Policy.