A Service Level Agreement is a contractual commitment between a provider and a customer that defines the expected service level, usually measured as availability, response time, or support response.
A Service Level Agreement specifies measurable service targets, remedies for missing those targets, and the parties responsible. Common targets include monthly uptime percentages, maximum downtime windows, and support response times.
That contract form is why SLAs matter more in vendor relationships than internal engineering. Internal teams use SLOs as engineering targets. External customers need SLAs because they include financial or procedural consequences when targets are missed. The risk is treating SLAs as marketing numbers without operational tooling that can actually meet them.
Think of it like this. Think of a courier service promising two-day delivery. The promise on the website is the SLA; the internal sorting and routing targets are the SLOs.
Providers define service targets, measurement windows, and penalties or credits. Monitoring systems collect the underlying SLIs. Reports summarize performance against the SLA during each window. Missed targets may trigger service credits, refunds, or contract review.
"SLAs are only for external vendors." Internal platform teams also use them with consuming teams. "Uptime alone is the SLA." Performance, correctness, support response, and data retention often belong in the same agreement. "An SLA guarantees availability." It guarantees compensation when availability misses; it does not prevent the outage itself.
Creates trust and shared expectations, but requires accurate measurement, clear definitions, and enforceable remedies. Overly aggressive SLAs increase cost and reduce flexibility; weak SLAs provide no real protection.