Service Level Agreement (SLA)

What is a service level agreement?

A service level agreement (SLA) is a vendor's written promise about how well its service will run, most often how much of the time it will be up. It also says what you get if the vendor misses that promise.

The core of a SaaS SLA is often an uptime number, such as 99.9% per month. Uptime means the share of time the service works. At 99.9%, a 30-day month allows about 43 minutes of downtime before the promise is broken.

An SLA usually covers:

• The commitment: the uptime percentage, often by plan.
• How it is measured: what counts as "down" and who measures it.
• Exclusions: outages that do not count.
• The remedy: usually service credits, a discount on a future bill.
• How to claim: the steps and the deadline to ask for credits.

Plans often differ. Atlassian's SLA promises 99.9% for Premium plans and 99.95% for Enterprise, and excludes Free plans. Grafana Cloud's SLA sets a 99.5% monthly target.

What it looks like in a vendor's terms

A typical clause reads like this:

We will make the Service available with a Monthly Uptime Percentage of at least 99.9%. A minute counts as Downtime if more than 5% of requests fail, as measured by our systems. Downtime caused by scheduled maintenance, events outside our control or your own systems does not count. If we miss the target, you may request a Service Credit within 30 days. Service Credits are your sole and exclusive remedy for any failure to meet this SLA.

• "At least 99.9%": the promise is a monthly average, so one long outage and many short ones can count the same.
• "More than 5% of requests fail": a partial outage below that line is not downtime at all.
• "As measured by our systems": the vendor's own data decides.
• "Does not count": exclusions shrink what the promise covers. See force majeure for the "outside our control" part.
• "Request ... within 30 days": credits are not automatic, and a late claim loses them.
• "Sole and exclusive remedy": credits are all you get. You cannot also sue for the cost of the outage under the SLA.

Real SLAs follow this shape. Google Workspace's SLA counts a period as downtime when there is "more than a five percent user error rate." It also calls credits the "sole and exclusive remedy." Atlassian's SLA also uses a 5% error rate per minute and says credits are the customer's exclusive remedy.

Service credits are small

Credits are worth less than they sound. Google Workspace adds 3 days of service if uptime falls below 99.9% but stays at or above 99.0%, and caps credits at 15 days in a month. Atlassian Premium gives 10% of that month's fee for the same drop, and Grafana Cloud gives 10% for uptime between 99.0% and 99.5%. Claim windows are short: 30 days at Google, 15 days after month end at Atlassian, and 10 days at Grafana Cloud.

Why it matters to you

An outage costs you more than the vendor's fee. Your team stops work, your customers may be affected, and you may owe your own customers credits under your SLA. The vendor's SLA rarely covers any of that.

• Limited money back: credits are a slice of one month's fee, often only as a credit on a future bill, not cash.
• Your own promises: if you promise 99.9% to your customers and depend on a vendor that promises the same, any extra downtime of your own puts you below the line.
• Payment status: Atlassian gives credits only if your account is fully paid with nothing overdue or in dispute.
• Changes: SLAs are often web pages the main agreement links to. Atlassian's Customer Agreement lists the SLA among the policies it can modify by posting changes.

What many SaaS SLAs leave out

• Free and lower plans: often no SLA at all.
• Partial outages: a slow or half-broken service can stay under the error threshold.
• Data: an uptime promise does not cover data loss, backups or how fast data is restored. See business continuity and disaster recovery.
• Your real losses: lost revenue and staff time are not covered. The limitation of liability usually limits other claims too.
• A right to leave: an SLA may not let you end the contract after repeated misses.

What to check

• Your plan: confirm the SLA covers the plan and products you pay for.
• The downtime definition: check the error threshold and whether partial outages count.
• Exclusions: look at maintenance limits, notice for planned downtime and how broad the "outside our control" list is.
• Claim process: note the deadline and set a reminder to file after any outage.
• Repeated failure: ask for a right to terminate if the vendor misses the SLA several months in a row.
• Change rules: check whether the vendor can change the SLA during your term.

Support Policy

A support policy sets how a vendor handles your help requests: what it covers, when support is open and how fast it responds. Some vendors put this in their SLA. Others publish it as a separate page.

The core is a set of priority levels with a target response time for each. For example, Grafana Labs' Enterprise Support SLA sets a first response target of 2 hours for critical issues, 4 hours for production issues and 6 hours for general questions, around the clock.

Read the words closely. A response time is how fast someone replies, not how fast the problem is fixed. Grafana calls these targets and commits only to "commercially reasonable efforts." A breach of this support SLA earns a $500 credit per incident, which you must request within 30 days.

Scope matters too. Grafana excludes issues if bills are overdue, if you run software more than 12 months behind the current release, or if you will not give access for troubleshooting. Check which plan gets which level, which channels you can use and what is out of scope.

How Venpo helps

Venpo watches the SLAs and support policies of the vendors you use and emails you a plain-English alert when they change, such as a lower uptime target, a new exclusion or a shorter claim window. Each vendor has a change history, so you can see which version applied when an outage happened.