Service Level Agreement Outline
How it works
A Service Level Agreement (SLA) defines the performance standards a service provider must meet, the metrics used to measure performance, and the remedies available when standards are not met. The SLA Outline generates a framework for IT, cloud, managed services, and professional service SLAs.
**SLA vs. contract** An SLA is typically an exhibit or schedule to a master service agreement — it details quantitative performance expectations while the master agreement covers legal terms (liability, IP, confidentiality). Some SLAs stand alone; in that case, they must include both commercial and legal terms.
**Key SLA metrics** Uptime / availability: "99.9% availability" = 8.77 hours downtime per year; "99.99%" = 52.6 minutes per year; "99.999% (five nines)" = 5.26 minutes per year. Response and resolution time: tiered by severity (P1/P2/P3): P1 (system down) = 1-hour response, 4-hour resolution; P2 (major function impaired) = 4-hour response, 24-hour resolution; P3 (minor issue) = 24-hour response, 72-hour resolution. Throughput, error rates, and latency for APIs and data services.
**Service credits** Define the remedy for SLA breaches: service credits as a percentage of monthly fees for each percentage point of availability below the guaranteed level. Specify: credit request process and deadline, maximum credit cap (typically 30–50% of monthly fees), and exclusions (scheduled maintenance, force majeure, customer-caused outages).
**Exclusions** Define what doesn't count against the SLA: scheduled maintenance windows (with advance notice); outages caused by customer's infrastructure; force majeure events; third-party service outages outside the provider's control.
This tool generates an outline. SLA negotiations depend heavily on your specific service and risk tolerance — review with a licensed technology attorney.
Frequently Asked Questions
- A service level agreement defines measurable performance standards for a service — uptime, response time, resolution time — and the remedies when those standards aren't met. SLAs are standard in IT services, cloud/SaaS agreements, managed services, and outsourcing contracts. They convert vague promises ('reliable service') into enforceable obligations ('99.9% monthly uptime, 4-hour resolution for P1 incidents'). Without an SLA, you have no contractual basis to demand credits or terminate for poor performance.
- Availability/uptime (percentage of time service is operational, typically 99.9% = 8.7 hours downtime/year, 99.99% = 52 minutes/year), response time (for support tickets by priority level), resolution time (how long to fix issues), performance benchmarks (page load times, API response times), data recovery objectives (RPO: how much data can be lost; RTO: how quickly to restore service), and measurement methodology (how uptime is measured — scheduled maintenance excluded or not).
- Service credits (percentage of monthly fee credited for downtime beyond the SLA threshold) are the most common remedy. Example: if uptime falls below 99.9%, the customer receives a 10% credit; below 99.0%, a 25% credit. Credits are typically capped (often at one month's fees) and are the exclusive remedy — the customer can't sue for additional damages from downtime. Some SLAs allow termination without penalty if violations exceed a threshold in consecutive months.
- Standard exclusions: scheduled maintenance windows (with advance notice), force majeure events (natural disasters, internet backbone failures), downtime caused by the customer's actions or configuration, third-party service failures outside the provider's control, and free or beta features. Be specific: 'monthly scheduled maintenance up to 4 hours per month with 48 hours notice is excluded from uptime calculations.' Poorly defined exclusions lead to disputes about whether a specific incident counts against the SLA.