A Service Level Agreement makes a promise a regular Terms and Conditions document never makes: a specific, measurable commitment about how the product will perform, backed by a stated consequence if the vendor misses it. Most SaaS terms disclaim performance entirely, “the service is provided as is.” An SLA is the document that walks that disclaimer back for the parts of the relationship a paying customer actually needs certainty on: uptime, and how fast someone answers when something breaks.
Setting the Uptime Commitment
The uptime commitment is a percentage, almost always somewhere between 99% and 99.99%, and the gap between those numbers is much larger than it looks written down.
Uptime Commitment to Allowed Downtime
| Allowed Downtime / Month | Allowed Downtime / Year | |
|---|---|---|
| 99% | 7h 12m | 3d 16h |
| 99.9% | 43m 12s | 8h 46m |
| 99.95% | 21m 36s | 4h 23m |
| 99.99% | 4m 19s | 52m 34s |
| 99.999% | 26s | 5m 15s |
Those figures are simple arithmetic against a 30-day month and 365-day year, not a benchmark or a survey number, and they are worth working through before picking a commitment, because “99.9%” sounds close enough to 100% that vendors sometimes commit to it without pricing in what 43 minutes of downtime a month actually costs in credits once it is written into a contract. 99.9% (“three nines”) is the most common commitment for a general SaaS product; 99.95% and 99.99% show up on infrastructure and payments-adjacent products where an outage has a direct dollar cost to the customer; 99% is common for lower-tier or free plans where the vendor is explicit that uptime is best-effort, not guaranteed.
The clause also has to define how uptime is measured, not just the target: whether it is measured monthly or over a rolling window, which components count (API availability, dashboard availability, both), and whether the vendor’s own monitoring is authoritative or a third-party monitoring service is the tiebreaker in a dispute. A commitment with no measurement method attached is not enforceable, because there is nothing in the contract that says how a miss gets detected or proven.
What Counts Against Uptime, and What Doesn’t
Every uptime clause needs an exclusions list, and skipping it is one of the more common drafting mistakes in a first-draft SLA. Standard exclusions cover scheduled maintenance announced with advance notice (commonly 24 to 48 hours), force majeure events outside the vendor’s control, outages caused by the customer’s own misconfiguration or third-party integrations the customer connected, and denial-of-service attacks or similar malicious activity targeting the customer specifically. Without these carve-outs, a planned two-hour maintenance window at 3am on a Sunday counts as a full breach of a 99.9% commitment, which is not what either party actually intended when they signed.
Structuring Service Credits
A service credit is the SLA’s actual enforcement mechanism: a percentage of the affected period’s fees, refunded or credited toward the next billing cycle, tied to how far below the committed uptime the vendor actually fell. A workable credit structure is tiered rather than all-or-nothing, so a small miss and a severe outage are not treated the same way.
The credit request step matters and is easy to leave out of a first draft: most SLAs put the burden on the customer to request the credit within a defined window, often 30 days after the affected billing period closes, rather than crediting automatically. That protects the vendor from an open-ended liability tail and gives both sides a clear deadline to work against. The agreement should also state, explicitly, that service credits are the customer’s sole and exclusive remedy for an uptime miss, which is what keeps an SLA breach from also becoming grounds for a separate breach-of-contract damages claim under the main services agreement.
Support Response Tiers
The second half of most SLAs has nothing to do with uptime: it commits to how fast the vendor responds once a customer reports a problem, and it is usually structured by severity rather than a single blanket response time. A common structure defines four tiers: a critical or P1 issue (the product is down or a core feature is completely unusable for the customer) commits to first response within roughly one hour; a high or P2 issue (a major feature is broken but a workaround exists) commits to four hours; a medium or P3 issue commits to one business day; a low or P4 issue, cosmetic bugs or feature requests, commits to two or three business days. Response time is not resolution time, and conflating the two is a common drafting error: the SLA should be explicit that it commits to how fast someone acknowledges and starts working the ticket, not how fast the underlying bug gets fixed.
Putting It Together
A complete SLA reads, in order, as: the uptime commitment and how it is measured, the exclusions that don’t count against it, the credit structure and how a customer claims it, and the support response tiers by severity. Each section is independently useful, but a customer evaluating a vendor almost always reads the uptime number and the top support tier first, so those two figures need to be accurate and defensible before anything else in the document gets drafted.
An SLA is typically a schedule attached to the main SaaS agreement or Terms and Conditions rather than a fully standalone contract, alongside a Data Processing Agreement covering how the vendor handles the customer’s data. Our Terms and Conditions generator builds the umbrella agreement an SLA schedule attaches to; if the customer relationship also involves processing personal data on the customer’s behalf, see whether you need a Data Processing Agreement as the companion document most SaaS vendors negotiate alongside the SLA.