SLA: what a service level agreement is and how it works

An SLA (Service Level Agreement) is the part of the contract that defines, in numbers, the service quality a SaaS vendor promises to deliver. Instead of a vague promise that the product will work, the SLA sets objective targets, such as monthly availability and the time to respond to a ticket, and spells out what happens if they are not met.

It exists because the customer is outsourcing something critical to their own business. By signing an SLA, the vendor turns trust into a measurable obligation, and the customer gains predictability over a service they do not control. That is why the SLA is central to enterprise sales, where legal and procurement read every clause before closing.

A well-written SLA is specific and measurable. It avoids adjectives and swaps "reliable service" for numbers you can audit every month.

• Guaranteed uptime: the minimum availability, almost always expressed as a monthly percentage.
• Response and resolution time: how fast support acknowledges and resolves a ticket, usually by severity.
• Maintenance windows: the planned periods that do not count as downtime.
• Credits and penalties: the compensation owed when the target is missed.
• Support channels and hours: where and when the customer can ask for help.

The more precise these definitions, the smaller the chance of a dispute later. A good SLA even makes clear how availability is measured, because the same outage can count or not depending on the method.

The most visible number in an SLA is availability, almost always expressed as a percentage of time online. Intuition is misleading: the gap between 99% and 99.9% looks small, but in downtime it is huge.

• 99%: about 3.65 days of downtime per year.
• 99.9% (three nines): about 8.76 hours per year.
• 99.99% (four nines): about 52.6 minutes per year.
• 99.999% (five nines): about 5.26 minutes per year.

That is why each extra nine costs dearly in engineering and redundancy. A 95% SLA, for example, allows more than 18 days of downtime per year, which is rarely acceptable for a mission-critical service.

Three similar acronyms describe different layers. The SLA is the external agreement, with contractual consequences. The SLO (Service Level Objective) is the internal target the team pursues, almost always stricter than the SLA to build a safety margin. The SLI (Service Level Indicator) is the indicator actually measured, such as the percentage of successful requests.

• SLI: what you measure.
• SLO: the internal target you want to hit.
• SLA: the contractual promise to the customer, with a penalty if it fails.

The practical order is to measure the SLI, set an SLO comfortably above the SLA, and only then promise the SLA to the customer. That way the team notices the problem before it becomes a breach of contract.

What gives an SLA teeth are the consequences. The most common mechanism is the service credit: if availability drops below what was promised, the customer gets back a percentage of what they paid, usually on a scale that grows as the failure worsens.

It is worth knowing the limits of this model. The credit is usually proportional to the subscription fee, not to the customer real loss, and it almost always has to be claimed within a deadline. For the vendor, paying credits often is an operational warning, not just a financial one: it signals that the service is eroding the trust the contract was meant to protect.

A well-calibrated SLA is both a shield and a selling point. It bounds the vendor responsibility and signals maturity to the buyer. As more operations move to the cloud, and Gartner forecasts worldwide public cloud spending to reach $723 billion in 2025, the availability guarantee stops being a detail and becomes a decision criterion.

The impact goes beyond the contract. Repeated outages and missed SLAs drag down the customer health score and are one of the classic triggers of churn in enterprise accounts. Treating the SLA as a living promise, monitored and kept, is a direct way to protect recurring revenue.