What Is an SLA? Service Level Agreement Meaning, Types and Examples

People look up "SLA meaning" when the acronym appears in a hosting contract, a help desk setting or a job advert. Most explanations blur three things: the agreement, the target written inside it, and the measurement behind the target.

This guide separates them, for business owners, support leads and students: the definition, the uptime table with its arithmetic, real SLAs from AWS, Google and Cloudflare, support SLAs by priority, compliance maths and a first SLA in five steps.

What is an SLA, and what does SLA mean?

An SLA, short for service level agreement, is a written agreement in which a provider promises a customer a measurable level of service, for example a website that is up 99.9% of the month or emails answered within one business day, and states what the customer gets if the promise is broken.

The same letters mean other things elsewhere, such as a sealed lead-acid battery or stereolithography in 3D printing. This page is about the service level agreement.

What does SLA stand for, and where does the term come from?

SLA stands for service level agreement, a core term of IT service management now used by cloud providers and support teams too. Two primary sources define it.

The ITIL glossary (2011 edition, Crown copyright) defines an SLA as "An agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer." ITIL is a body of IT service management guidance; that glossary records that the UK government portfolio it belonged to was owned by CCTA, then OGC, then from June 2010 the Cabinet Office. In 2021 PeopleCert completed its purchase of AXELOS, the company set up in 2013 to manage ITIL, and PeopleCert now lists ITIL (Version 5) as the new edition alongside ITIL 4 (checked 12 November 2026).

Google's Site Reliability Engineering (SRE) book gives the engineering view in its chapter on service level objectives, by Chris Jones, John Wilkes and Niall Murphy with Cody Smith: an SLA is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain." No primary source we found names an inventor of the phrase.

What are the three parts of every SLA?

Every SLA contains three things: the service it covers, a measurable target, and what happens when the target is missed. Without all three it is a description or a goal, not an SLA.

1. The service and its scope

The scope names the service, the customers, the hours and the exclusions. AWS's compute SLA, for example, excludes outages caused by the customer's own actions, equipment or software.

2. The measurable target

The target pairs a measurement with a threshold and a time window, usually a calendar month. The measurement is the service level indicator (SLI), "a carefully defined quantitative measure of some aspect of the level of service that is provided," in the SRE book's words. The threshold is the service level objective (SLO), "a target value or range of values for a service level that is measured by an SLI."

3. The consequence of a miss

A consequence, such as a service credit or a right to end the contract, turns a target into an agreement. The SRE book's test: ask "what happens if the SLOs aren't met?" With no explicit consequence, "you are almost certainly looking at an SLO."

How does an SLA work? A worked example

An SLA works by measuring one thing the same way every period, comparing the result with the target, and applying the agreed consequence when it falls short. Here is one example, for a software company with three support people.

1. Agree the service. Email and chat support for paying customers, Monday to Friday, 9:00 to 17:00 New York time, holidays excluded.
2. Pick the indicator. First response time in business hours, from the customer's first message to the first reply written by a person. Auto-replies do not count.
3. Set the target. 90% of normal-priority requests get a first reply within 4 business hours, per calendar month.
4. Attach the consequence. Below 90% in two consecutive months, affected customers get a 5% credit on the next invoice.
5. Measure. In October, 480 normal-priority requests arrived and 444 got a first reply within 4 business hours.
6. Report and act. Compliance is 444 ÷ 480 = 92.5%. The target is met, no credit is due, and the 36 late replies are reviewed for causes.

What is the difference between an SLA, SLO, SLI, KPI and OLA?

An SLI is the measurement, an SLO is the target for it, an SLA is the agreement that attaches a consequence to the target, a KPI is any metric a business manages by, and an OLA is an agreement between two teams inside one organisation.

The ITIL glossary defines a key performance indicator (KPI) as "A metric that is used to help manage an IT service, process, plan, project or other activity," and an operational level agreement (OLA) as "An agreement between an IT service provider and another part of the same organization." An agreement with an outside supplier is an underpinning contract.

What are the types of SLA?

SLAs are grouped by structure (customer-based, service-based or multi-level) and by who is on the other side (a customer, an internal team or a supplier).

What does 99.9% uptime mean in downtime?

99.9% uptime means a service may be unavailable for 0.1% of the time: 8 hours 45 minutes 36 seconds in a 365-day year, 43 minutes 48 seconds in an average month and 1 minute 26.4 seconds a day. Each extra nine cuts the allowed downtime tenfold.

The arithmetic, once: 99.9% leaves 0.1%, or 0.001. A 365-day year has 365 × 24 × 60 = 525,600 minutes, and 525,600 × 0.001 = 525.6 minutes, or 8 hours 45 minutes 36 seconds. Months are one twelfth of that year (43,800 minutes); days are 1,440 minutes. We computed every row with a script.

The SRE book's chapter on embracing risk agrees: "a system with an availability target of 99.99% can be down for up to 52.56 minutes in a year." Most SLAs measure per calendar month, so at 99.9% a 30-day month allows 43.2 minutes and a 31-day month 44.64. The SRE book treats this allowance as an error budget, the unreliability still left to spend before the target is missed.

Definitions of "unavailable" differ, so read them before comparing providers.

What do real SLAs look like? Six published examples

Real SLAs define the target, the measurement, the credits and the claim process. These six are quoted from Amazon's, Google's, Cloudflare's and Zendesk's own pages, opened on 12 November 2026.

Amazon EC2: 99.99% per region, credits in three tiers

The Amazon Compute SLA (last updated 25 May 2022) commits AWS to "commercially reasonable efforts" toward 99.99% monthly uptime for EC2 across two or more availability zones, and 99.5% for a single instance, counting the percentage of minutes in the month that EC2 was unavailable.

Credits are a percentage of that region's monthly EC2 bill, apply against future payments and "will not entitle you to any refund." You claim them, with your own logs, by the end of the second billing cycle after the incident.

Google Workspace: 99.9%, credited in days of service

The Google Workspace SLA (last modified 31 August 2026) promises "at least 99.9% in any calendar month." Below that the customer gets 3 extra days of service, below 99.0% 7 days and below 95.0% 15 days, the monthly cap. Downtime means a user error rate above five percent, and the customer must open a support case within thirty days to claim.

Cloudflare Business: "100% of the time"

Cloudflare's Business SLA says the service "will serve Customer Content 100% of the time without qualification." The remedy is a formula, "(Outage Period minutes * Affected Customer Ratio) ÷ Scheduled Availability minutes," capped at one month of fees in twelve months. A 100% SLA means a qualifying outage earns a credit, not that outages cannot happen.

AWS Support: response targets without a credit

The AWS Support plans page lists human response times by severity. On Business Support+: under 30 minutes for a business-critical system down, under 1 hour for a production system down, under 4 hours for production impaired, under 12 hours for system impaired, under 24 hours for general guidance. A footnote on the fastest times says AWS "will make every reasonable effort to respond" within them, and no credit is offered for a miss, so by the SRE test these are objectives.

Google Search: no public SLA

The SRE book names Google Search as "an example of an important service that doesn't have an SLA for the public."

Zendesk: SLA policies inside a help desk

Zendesk's article on defining SLA policies calls an SLA "an agreed upon measure of the response and resolution times" and offers seven metrics, set per ticket priority in business or calendar hours.

What is a good SLA target?

A good SLA target matches what customers need, is already met with room to spare, and is written as a percentage of cases within a time limit. The SRE book's advice opens with "Don't pick a target based on current performance," recommends a tighter internal objective as a safety margin, and warns that "users will come to rely on its current performance" if you overachieve.

The last two rows are vendors measuring their own customers, not promises. The first response time benchmarks post lists more by channel, with source and sample.

What does an SLA mean in customer support?

In customer support, an SLA is a promise about how quickly people reply to and resolve requests, set per priority and channel and usually counted in business hours.

First response time is the time from a request to the first reply from a person. Next response time runs from the customer's oldest unanswered message to the team's next reply, so a ticket cannot go quiet after a fast first answer. Resolution time runs from the request until the issue is solved. If an AI support agent such as PepoChat answers chats first, write down whether its answer counts as the first response.

This is a sample, not a benchmark; each target applies to 90% of requests a month. Customer-facing wording can be this plain:

Our support hours are Monday to Friday, 9:00 to 17:00 [time zone], excluding public holidays in [country].

We aim to send a first reply within these times, counted in support hours:
- Urgent (the service is down or you cannot take payments): 1 hour
- High (something is broken for you): 4 hours
- Normal (questions and how-to requests): 1 business day
- Low (feedback and feature requests): 2 business days

We meet these targets for at least 90% of requests each month. Outside support hours, [our chat assistant answers common questions / leave a message], and a person replies by email on the next business day.

These are service targets. They do not entitle you to a refund or credit unless your contract says so.

How do business hours and pausing the clock work in an SLA?

A business-hours SLA clock runs only during the agreed support hours and stops at closing time, at weekends and on listed holidays. Some timers also pause while the team waits for the customer.

Take an email with an 8-business-hour first response target and hours of 9:00 to 17:00, Monday to Friday. It arrives on Friday at 16:30: the clock runs 30 minutes, stops, restarts on Monday at 9:00, and the reply is due at 16:30. A reply on Monday at 10:15 used 1 hour 45 minutes of business time, though the customer waited 65 hours 45 minutes. Report both numbers.

Pausing depends on the metric. In Zendesk's definitions, requester wait time pauses while a ticket is Pending (waiting for the customer), agent work time pauses on Pending and On-hold, and total resolution time pauses only when solved. A ticket that gets 2 hours of work, waits 2 business days (16 business hours) for a screenshot, then takes 5 more hours shows 7 business hours on a paused clock and 23 on an unpaused one, so write down which clock you use. PepoChat's Team availability setting, for example, takes the same time zone and weekly hours and changes what the agent promises outside them.

How do you calculate SLA compliance?

SLA compliance is the share of measured cases that met their target: divide the cases that met it by all cases measured against it and multiply by 100.

SLA compliance (%) = cases that met the target ÷ cases measured against the target × 100

Uptime (%) = (minutes in the period − minutes unavailable) ÷ minutes in the period × 100

Edge case: open tickets. In November, 500 normal-priority requests arrived. By month end 475 had a first reply, 440 of them within 4 business hours. Of the 25 still waiting, 10 were already past 4 hours and 15 were not. The 10 count as misses; the 15 move to next month. Compliance is 440 ÷ (475 + 10) = 440 ÷ 485 = 90.72%. Ignoring all unanswered requests would flatter it: 440 ÷ 475 = 92.63%.

Edge case: month length. A 44-minute outage against a 99.9% SLA gives (43,200 − 44) ÷ 43,200 × 100 = 99.898% in a 30-day month, a miss, but (44,640 − 44) ÷ 44,640 × 100 = 99.901% in a 31-day month, a pass.

What happens when an SLA is breached?

An SLA breach is a measurement period in which the result falls below the agreed target; what follows is whatever the agreement says, most often a service credit the customer must claim. A service credit is a discount on future bills, or extra days of service, given as the remedy for a miss.

A worked AWS example: a company spends $2,000 a month on EC2 in one region, and its multi-zone deployment is unavailable for 50 minutes in a 30-day month. Uptime is (43,200 − 50) ÷ 43,200 × 100 = 99.884%, the 10% tier, so the credit is $200 if claimed in time. The 30% tier needs more than 7 hours 12 minutes of downtime, the 100% tier more than 36 hours.

How do you write an SLA for a small support team?

Check what customers need against what you deliver today, promise a little less, and attach a consequence you can live with.

1. Measure four weeks. Pull first response and resolution times per channel and note the 90th percentile, not just the average.
2. Write down honest hours. Channels, hours, time zone and holidays. If nobody works nights, do not imply 24/7 replies; 24/7 support without a night shift covers the options.
3. Choose two or three metrics by priority. First response and resolution are enough to start.
4. Set targets as percentages with a margin. "90% within 4 business hours" when you hit 95% today.
5. Agree the consequence and review quarterly. Internal SLAs escalate to a manager; customer SLAs may carry credits. Have a lawyer read anything that goes into a contract.

What are the most common SLA mistakes?

The most common SLA mistakes are unmeasured targets, 24/7 promises from a daytime team, and averages instead of the share of cases within target.

• Targets nobody measures. If the help desk cannot time a metric, the SLA is decoration.
• 24/7 promises with a 9-to-5 team. Use business hours and say what happens after them, as the offline chat message examples show.
• Averages instead of percentages. Twenty tickets with a 4-hour target: 16 answered in 1 hour, 4 in 9 hours. The average is (16 + 36) ÷ 20 = 2.6 hours, yet 20% breached. The SRE book prefers percentiles to "the mean (arithmetic average)" for this reason.
• Counting auto-replies. An acknowledgement is not a first response.
• Too many metrics. "Have as few SLOs as possible," says the SRE book.
• Overachieving for years. Google deliberately takes its global Chubby service down in any quarter where real failures have not brought availability below target, so nobody depends on uptime that was never promised.

Is an SLA legally binding?

An SLA binds the parties when it forms part of a contract, within what that contract and the applicable law allow; a response target on a help page with no contract behind it usually states an intention. AWS's compute SLA calls itself "a policy governing the use of" EC2 and works alongside the AWS Customer Agreement.

An SLA is also not a guarantee of quality: fast, wrong answers can meet it, so track resolution and satisfaction too, as AI chatbot metrics that matter explains. This is general information, not legal advice.

How PepoChat fits into a support SLA

PepoChat is our product; we include it where it fits and say where other tools are the better choice. It is not a help desk: it has no SLA timers, breach alerts or compliance reports, and it publishes no uptime SLA of its own. Its place in an SLA is the first response.

The AI support agent answers every chat at once, at any hour, from your knowledge base, so a question sent at night gets an answer instead of joining the morning queue. When it cannot answer, or the visitor asks for a person, it hands over to the team inbox, where teammates set priority (low, normal, high or urgent) and assignment, and workspace members get an email; the human handoff guide walks through it. The Team availability card in widget customization sets what the agent promises: a teammate in the chat, your business hours with an away message of up to 300 characters, or email follow-up only, so the chat matches the hours in your SLA.

Teams that must report SLA compliance keep a help desk for it. PepoChat can create the ticket in Zendesk, Freshdesk or Zoho Desk with an AI-written summary and the visitor's email, and the help desk's SLA policy takes over. Every chat feature is on the free plan; start a free workspace to see how many first replies the agent handles on your traffic.

What to do next

• Compare four weeks of your own first response times with the first response time benchmarks before you promise anything.
• Read how the human handoff works, so the wait for a person after the AI is covered by your SLA too.
• Compare the plans on the pricing page: Free includes 100 AI replies a month, Starter at $39 a month includes 1,000.
• Create a free PepoChat workspace, no credit card needed, and set Team availability to match your support hours.
• Related explainers: What is a help desk?, What is CSAT? and What is NPS?.