Software Growth

SLA (Service level agreement)

An SLA is a contract promise about service quality, usually uptime and support response, with a stated remedy such as credits if you miss it.

An SLA is the part of your contract that says how reliable the service will be and what happens if it is not. Google's SRE book defines it as an explicit or implicit contract with users that includes consequences of meeting or missing the objectives, and adds a useful test: with no explicit consequence, you are almost certainly looking at an SLO, not an SLA.

SLI, SLO, SLA

  • SLI (indicator): a measurement, such as the share of requests that succeed.
  • SLO (objective): your internal target for that measurement, say 99.95%.
  • SLA (agreement): the external promise, usually set looser than the SLO, with a remedy attached.

Keep the SLO tighter than the SLA so you notice problems before you owe anyone money.

What a SaaS SLA contains

  • A monthly uptime commitment. EnterpriseReady says 99.9 percent is standard and 99.99 percent common among competitive providers.
  • What counts as downtime, and what is excluded, such as scheduled maintenance and customer-caused issues.
  • Support response times by severity (acknowledging and starting diagnosis, not necessarily fixing).
  • The remedy: usually service credits, not cash.
  • How the customer claims it, with a deadline.

Worked example of a credit

Suppose a customer pays $1,000 a month and your SLA promises 99.9% monthly availability, with a 10% credit if you fall below 99.9% and 25% below 99%. A 30-day month has 43,200 minutes, so 99.9% allows 43.2 minutes of downtime. You have a 2-hour outage, which is 120 minutes.

That is below 99.9% but above 99%, so the credit is 10% of $1,000, or $100. One bad incident across 40 such customers costs you $4,000, which is why you size the commitment to what you can really deliver.

Common mistakes

  • Copying a competitor's 99.99% when your architecture is one server and one database.
  • Promising credits you cannot calculate because you do not measure availability.
  • Putting the SLA on the public pricing page for every plan, instead of only for plans that include it.
  • Ignoring that an SLA is a lever in negotiation: large buyers ask for higher numbers, and each extra nine is expensive.

When a small SaaS should care

Do not offer an SLA to self-serve customers. Publish a status page and a target instead. Add a formal SLA to a higher plan or enterprise contract when buyers ask, usually alongside a SOC 2 report. Before you sign one, check your last six months of incidents. If you could not have met 99.9% in three of them, fix reliability first. A good support process matters here too, since reliability problems that go unanswered raise churn.

Sources

Back to the SaaS glossary