What Should Your SLA Actually Promise?

An SLA that promises “99.9% uptime” has told you almost nothing until you know how uptime is measured, what does not count against it, and what actually happens when the number is missed.

Service level agreements are among the most quoted and least read provisions in software contracts. The headline percentage travels well in a sales conversation. The definitions and exclusions that determine what it is worth usually sit a page above it.

Key takeaways: The percentage is often the least important part of an SLA. The definition of downtime, the list of exclusions and the remedy do the real work. A service credit is generally a pricing adjustment rather than compensation for business loss. Whether credits are a customer’s only recourse is a commercial and legal question worth resolving before signing, not after an outage.

The Percentage Is Arithmetic. Start There.

Uptime commitments are usually stated per month or per year. The allowance is simple arithmetic, and it is worth working out once so the number stops being abstract. A 30-day month contains 43,200 minutes. A calendar year contains 525,600.

Commitment	Allowed downtime, 30-day month	Allowed downtime, year
99%	7 hours 12 minutes	3 days 15.6 hours
99.5%	3 hours 36 minutes	1 day 19.8 hours
99.9%	43.2 minutes	8 hours 45.6 minutes
99.95%	21.6 minutes	4 hours 22.8 minutes
99.99%	4.32 minutes	52.56 minutes

The step from 99.9% to 99.99% is not a rounding difference. It is the difference between a bad afternoon and a bad four minutes, and on the provider’s side it usually reflects genuinely different architecture and cost.

Note which period applies. A monthly measurement window resets the allowance twelve times a year. An annual window lets a single long outage consume the entire budget. The same headline percentage can mean materially different things depending on the window.

The Definition of Downtime Does More Work Than the Number

This is where most service level agreements are actually won or lost, and it is usually a single defined term sitting above the commitment.

The governing law may affect how particular SLA terms operate, so the contract should be reviewed as a whole rather than clause by clause in isolation.

Worth asking what counts as unavailable:

• Total unavailability, or degraded performance too? If the platform responds in forty seconds instead of failing outright, many agreements record no downtime at all. If latency matters to the business, the agreement has to say so.
• The whole service, or a feature? An agreement that measures only the core application may register nothing when reporting, the API, or single sign-on is unavailable.
• Measured by whom, from where? Provider-side monitoring from inside its own network can show availability the customer did not experience. Some agreements specify an external monitoring point or accept customer-side evidence.
• What is the minimum increment? If downtime is counted only in whole five- or ten-minute blocks, a series of shorter interruptions can disrupt a working day and still score as zero.
• Who has to notice? Some agreements count only downtime the customer reports and tickets within a stated window, which moves the burden of detection onto the customer.

A generous percentage attached to a narrow definition of downtime may be worth less than a modest percentage attached to a broad one.

Exclusions Are Where the Allowance Quietly Grows

Every SLA excludes some categories from the calculation. The existence of a list is ordinary. Its breadth is negotiable.

Scheduled maintenance is the most common exclusion. Look at whether it is capped, whether it must fall inside a defined window, and how much notice is required. Scheduled maintenance with no hour limit and no notice requirement can absorb an unlimited amount of planned unavailability.

Emergency maintenance deserves a separate look, because it is the exclusion that most often carries no cap at all.

Third-party and upstream failures. Most platforms run on infrastructure they do not own. Where the agreement excludes anything caused by a cloud provider, CDN or payment processor, a meaningful share of realistic outages may fall outside the commitment. In practice this is the exclusion customers most often overlook.

Customer-caused issues, force majeure and beta features round out the usual list. Beta and early-access exclusions matter more than they sound when a feature stays in beta for two years.

Read the exclusions and the percentage together. They are one provision expressed in two places.

Service Credits Are a Pricing Adjustment

When a provider misses the commitment, the standard remedy is a service credit: a percentage of the fee for the affected period, applied against future invoices.

Two features of credits are worth understanding before relying on them.

Credits are usually proportional to what was paid, not to what was lost. A customer paying a modest monthly subscription whose operations stopped for a day is typically looking at a credit measured against that month’s fee. That is the design rather than a defect — the credit adjusts the price of the service; it does not indemnify the business consequence.

Credits frequently have to be claimed. Many agreements require the customer to request the credit in writing within a set number of days after the incident and treat an unclaimed credit as waived. Credits are often not automatic.

The sole-remedy question. Many agreements state that service credits are the customer’s sole and exclusive remedy for a failure to meet the commitment. Whether that limit operates, and against what kinds of failure, depends on the wording of the provision, how it interacts with the contract’s broader limitation of liability and any carve-outs, and the governing law. A lawyer reviewing the agreement can also assess whether the credit provision raises any separate questions under the governing law. These are questions to raise with counsel about a specific agreement rather than assumptions to carry into a negotiation.

What can be said more generally: where a service failure would cause a business loss far larger than the fees, a credit-only remedy has not addressed that loss. Provisions addressing that broader exposure may appear elsewhere in the contract, including the limitation of liability, applicable carve-outs, termination rights, or insurance requirements.

Support Response Times Are Not Uptime

Service level agreements commonly bundle two different promises, and conflating them causes real disappointment.

Availability is whether the service is running. Support responsiveness is how quickly someone replies when it is not.

Support commitments are usually tiered by severity, and the severity definitions deserve to be read as closely as the downtime definition — particularly the question of who assigns the severity. Where the provider classifies incidents unilaterally, the response commitment is softer than it appears.

It is also worth separating response from resolution. Most support commitments promise a first response within a stated period. Fewer promise a fix within any period, and those that do commonly promise a workaround rather than a repair.

Chronic Failure Deserves a Different Remedy

A single bad month is a credit. A pattern is a different problem, and credits scale badly against it: the worse the service, the more the customer pays for a product that is not working, less a small discount.

Agreements sometimes address this by giving the customer a right to terminate without penalty where the commitment is missed in some number of consecutive or rolling months, occasionally with a pro-rated refund of prepaid fees. Whether such a right exists is a matter of what the agreement says. It is a drafting point to negotiate for, not something to assume is present. Where chronic failure would be material to the business, that is worth raising while the contract is still open.

What to Look at in Your Own Agreement

Whether you are signing a vendor’s SLA or sending your own to a customer:

The following checklist identifies provisions to locate and questions to discuss with counsel. It is not a substitute for legal advice about a particular agreement, service, outage, or dispute.

1. Locate the definition of downtime before reading the percentage.
2. Identify the exclusions and ask what share of realistic outages they cover.
3. Confirm the measurement window — monthly or annual — and who measures.
4. Confirm whether credits are automatic or must be claimed, and by when.
5. Compare the credit to the business exposure the service supports, and ask which provisions address the difference.
6. Compare the SLA against the limitation of liability. They are frequently drafted by different people at different times and do not always agree.
7. Ask what the agreement provides if the commitment is missed repeatedly.

For a provider drafting one, the same list read in reverse is a useful check on whether the commitment can actually be met. A service level agreement is one of the few contract provisions that commits the engineering team, not only the legal one.

Related reading: how to evaluate a liability cap, enterprise SaaS agreements, MSAs and DPAs, when a lawyer should review a SaaS contract, and API and vendor dependency terms.

How Accord & Shield Legal Helps

Accord & Shield Legal reviews and negotiates commercial contracts and technology agreements for businesses in Arizona, California and Texas, including the availability, support and remedy provisions that determine what recourse remains when a service fails. For software-specific agreements, see our SaaS and software agreement practice.

Nadine Deeb is admitted in Arizona, California and Texas. Before private practice, she served as the sole in-house legal resource at a California technology company, supporting a workforce operating across nineteen states.

Legal Information Only: This article provides general information for businesses and does not provide legal advice. Service level obligations, remedies, and contract rights depend on the complete agreement, the facts, and the governing law. Reading this article, contacting Accord & Shield Legal, PLLC, or submitting information through the firm’s website does not create an attorney client relationship. The firm represents a client only after completing a conflicts check and entering into a signed engagement agreement. Do not send confidential or sensitive information until representation is confirmed.