A service-level agreement (SLA) states the level of service people can expect and the consequences if it is not met. It can set minimum or maximum limits for availability, support, or issue resolution. For a service you depend on, an SLA helps you judge whether its commitments are adequate for your business. For a service you provide, it makes your own commitments clear to users. section 10.1.2 section 10.5
A cloud availability commitment
An illustrative AWS EC2 SLA specifies 99.99% monthly uptime and a 10% bill credit if that commitment is missed. The useful question is not just whether a credit exists: could your business tolerate the interruption, and what would it mean for the availability you promise your own customers? section 10.1.2
Set or review commitments according to the service’s importance. An SLA may address:
- Availability over a stated period, recognizing that higher reliability can cost more and that different systems can tolerate different amounts of downtime. section 10.1.2
- When an inquiry will be acknowledged, including business-hours and out-of-hours response. section 13.2.1
- Expected bug or issue resolution, monitoring, software patches, and limits on support effort where relevant. section 10.1.2 section 13.2.1
- The recourse or compensation available when a commitment is missed. section 10.1.2 section 10.5
Agree on support levels with sales, product, finance, and executive leadership: they must reflect what clients need, what can be sold, and what the team can deliver. If you promise out-of-hours support, choose a staffing approach and fund it; goodwill alone is not a coverage plan. Keep track of the SLAs for third-party services your enterprise relies on, as well as the SLA you offer internally or externally. Seek legal advice before signing or producing the agreement. section 13.2.1 section 10.6 section 10.0
