SLA Examples and Templates

Most people looking for an SLA template are not trying to learn what an SLA is. They have a renewal in three weeks, a service desk missing deadlines nobody ever agreed, or a supplier contract with a beautiful availability number and no definition of how availability gets measured. They need a document by Friday.

So this page is a library of artefacts: templates and worked examples for five common cases, each with the measurement rules that decide whether the commitment means anything. A target without a measurement rule is a wish with a number attached.

Key Facts: SLA Benchmarks Worth Borrowing

• Amazon commits to 99.99% monthly uptime for EC2 at the region level and 99.5% for a single instance, with credits of 10%, 30% or 100% of the affected charges (AWS Compute SLA, 25 May 2022).
• Google Cloud commits to 99.99% for Compute Engine instances in multiple zones and 99.9% for a single instance, but a customer must claim within 60 days to collect any credit (Google Compute Engine SLA).
• Microsoft states Azure support commitments by severity, not uptime: under 1 hour, 24x7, for Severity A on a Standard plan, against under 8 business hours for Severity C (Azure support).
• 57% of respondents said their most recent major outage cost more than $100,000, and one in five put it above $1 million (Uptime Institute, 2026).
• An SLA is a contract "that includes consequences of meeting (or missing) the SLOs they contain" (Google SRE Book).

The Anatomy of an SLA, Clause by Clause

Every usable SLA answers the same twelve questions. Templates that skip four or five of them get signed quickly and argued about later.

Where this page draws its line

The companion page, what an SLA is and how to set internal SLAs, owns the concept: the definition, the three classic types, and a five-step method for agreeing them. This page hands you the clauses and the numbers instead. One case is deliberately not repeated: the bilateral marketing-to-sales agreement already exists as the marketing-sales SLA template.

The clause checklist

The three dropped most often are measurement method, reporting and termination triggers, and they decide whether the agreement has teeth. A later section lists what each vague clause becomes.

SLA, SLO, SLI, OLA and the Underpinning Contract

Five terms get used interchangeably in meetings and mean different things on paper.

Google's SRE practice offers the test worth stealing: ask what happens if the target is missed, and "if there is no explicit consequence, then you are almost certainly looking at an SLO." It also warns off the perfect number, since "it's both unrealistic and undesirable to insist that SLOs will be met 100% of the time" (Google SRE Book).

The OLA vocabulary comes from ITIL, now published by PeopleCert, whose current scheme has moved past ITIL 4 to ITIL Version 5. The idea outlives any edition: promise a four-hour fix when the database team you depend on has never agreed to anything faster than a day, and you have committed someone else's calendar.

The Measurement Definitions That Decide Whether an SLA Is Honest

Two organisations can run identical targets and report wildly different compliance, purely from clock rules. Settle these in writing before anyone signs.

Question	Weak wording	Defensible wording
When does the clock start?	"On receipt of the request"	"At the timestamp the ticket is created in , including tickets the provider raises for the customer"
When does it pause?	Silent, or "while awaiting customer"	"Only while the ticket is Pending Customer, with paused time reported separately"
Business or calendar hours?	"Within 4 hours"	"Within 4 business hours, defined as 09:00 to 18:00 , Monday to Friday, excluding "
What is a resolution?	"Ticket closed"	"Service restored and confirmed by the requester; a workaround counts only for P3 and P4"
How do reopens count?	Silent	"A ticket reopened within days reverts to its original clock; the earlier closure is not a met target"
What share must comply?	"All tickets"	"95% of P1 and 90% of P2 per calendar month, across all tickets created that month"

Three of those decide most arguments. Pause rules are the biggest lever on a compliance number, because a team that can park a ticket in Pending Customer and stop its own clock will hit any target you set. Business hours change every number in the table: four business hours on a 09:00 to 18:00 calendar is almost 24 real hours if the request lands at 17:30 on a Friday. And reopens flatter a resolution figure, since a closure the customer reopens an hour later counts as one met target plus one new ticket. Track the reopen rate as its own process KPI.

Availability needs the same care. Google's Compute Engine SLA counts only "a period of one or more consecutive minutes of Downtime," so "partial minutes or intermittent Downtime for a period of less than one minute will not count" (Google Compute Engine SLA). A service can flap for fifty seconds at a time, all month, and report perfect availability.

Uptime Math: What Each Nine Actually Costs You

Availability percentages are hard to feel. Minutes are not. Every figure below is (1 minus the availability percentage) times the length of the period, using a 30-day month and a 365-day year.

Two gaps matter when you negotiate. Between 99.5% and 99.9% sit 2h 52m 48s a month, the difference between an outage a team works through calmly and one that eats an afternoon. Between 99.9% and 99.99% sit only 38m 53s, but that jump usually forces multi-zone deployment and a real on-call rota, so it's the expensive one.

Because most SLAs measure a calendar month, the allowance also moves with the month: at 99.9%, February allows 40m 19s against 44m 38s in a 31-day month, on an identical commitment.

Template 1: IT Service Desk Incident SLA

This is the template most organisations need first, and the one most often copied without its priority matrix, which is the part that does the work. Priority is not a field the requester picks. It's derived from impact and urgency, so two people cannot grade the same outage differently.

Response and resolution are separate commitments and should never collapse into one number. Response is the moment a human owns the ticket and says so; resolution is service restored. A team can be excellent at one and hopeless at the other, and a blended number hides that.

Those numbers are a starting point, not a benchmark to copy blind. Microsoft commits to under 1 hour for Severity A ("significant loss or degradation of services") 24x7 on a Standard plan and above, and under 8 business hours for Severity C (Azure support responsiveness). Note what that is: an initial response, not a resolution.

Incident Management SLA, to 1. Scope. Incident handling for . Requests, changes and project work sit in . 2. Service hours. P1 and P2 are handled 24x7. P3 and P4 run 09:00 to 18:00 , Monday to Friday, excluding . 3. Priority. Assigned from the matrix above by at triage. A re-grade does not reset the clock. 4. Targets. As per the response and resolution table above. 5. Measurement. Timings are taken in from ticket creation. The clock pauses only while the ticket is Pending Customer, and paused time is reported separately. 6. Resolution. Service restored and confirmed by the requester, or 2 business days without objection. For P1 and P2, a workaround is not a resolution. 7. Reopens. A ticket reopened within 5 business days resumes its original clock. 8. Exclusions. Planned maintenance notified business days ahead, incidents caused by customer-controlled systems or the third parties named in Appendix A, and events outside 's reasonable control. 9. Reporting. Compliance by priority, the reopen rate and the top three recurring causes, published by the fifth working day of each month. 10. Escalation. A P1 unresolved at 50% of its resolution target escalates to ; at 100%, to , who owns customer communication until closure. 11. Review. Quarterly, attended by . Targets change only by written agreement. 12. Repeated failure. Missing the P1 threshold in three consecutive months triggers a service improvement plan.

Clause 8 carries one rule: every exclusion must be named and testable. "Force majeure" is standard; "issues arising from customer environment complexity" is an escape hatch.

Template 2: Customer Support SLA

A support SLA behaves differently. The number that drives satisfaction most is not resolution time but next response time, the wait between replies once a conversation is under way. Plenty of teams hit first response targets and still frustrate customers because the second reply took two days. Channels differ too, so one blended target across chat and email overpromises on one of them.

Customer Support SLA, to 1. Covered channels. {Chat, email, phone, in-app}. Social media and community forums are best-effort with no commitment. 2. First response means a substantive human reply addressing the specific issue. An automated receipt does not satisfy this clause. 3. Next response means each subsequent reply while the conversation is open and awaiting . 4. Clock rules. Timing starts when the message arrives in and pauses only while the conversation is Awaiting Customer. A conversation awaiting the customer for days closes automatically and reopens on any reply, resuming the original clock. 5. Compliance. Measured monthly at the {90th} percentile, not the mean. 6. Escalation and reporting. Any conversation open beyond times its resolution target goes to and into the weekly review. Compliance per channel, reopen rate, and conversations breaching by more than hours are published monthly. 7. Exclusions. The third-party integrations named in Appendix A, custom development requests, and announced maintenance.

Two choices there are deliberate. A percentile rather than a mean stops an average concealing the week-old conversations that generate every complaint, and barring autoresponders from first response closes the most common way a support SLA gets gamed.

Example 3: An Internal Shared-Services SLA, and the OLA Behind It

Internal SLAs get written with the least ceremony and broken most often. Finance, HR, legal and IT serve customers with no contract, no credits and no alternative supplier, so the only enforcement is visibility and a review meeting.

Every target in the right-hand column depends on someone outside the team that signed up for it, which is exactly what an operational level agreement covers. Without the OLA, the team holding the visible SLA absorbs every upstream delay and stops believing in the target.

The second fix is defining a complete request. Most internal breaches are not slow work, they are work that started late because the request arrived without a budget code. Put that definition in a standard operating procedure, hold the clock until the request meets it, and report incomplete submissions next to the compliance number.

Where the flow crosses departments, map it first: a business process map shows the handoffs and queues, and the gap between cycle time and lead time tells you whether the target measures work or waiting. Keep the signed agreement with your process documentation, not in a slide deck.

Example 4: A Vendor SLA, Written From the Buyer's Side

Vendor SLAs arrive pre-written, optimised for the supplier: generous exclusions, credits nobody claims, and a measurement definition written by the party doing the measuring.

What to demand	What you will be offered	Why it matters
A named system of record and a measurement method	"Availability as measured by "	Whoever owns the measurement owns the result
Monthly reporting published by a fixed date	Reporting "on request"	An unpublished report is one nobody reads
Credits applied automatically on the vendor's own data	Credits on written claim within a short window	Claim windows expire, and the vendor knows it
Written root cause analysis for every severity 1	A verbal explanation on the next call	Without it, the same outage repeats
A monthly cap on excluded maintenance time	Unlimited maintenance with notice	Maintenance consumes the commitment
Notice before the vendor changes the SLA itself	"Vendor may amend by posting an update"	Your protection can be downgraded silently
A termination right for chronic failure, defined numerically	Termination for convenience, long notice	Without an exit, remedies are decorative

Two clauses are worth negotiation capital. The first is the chronic-failure trigger: "three breaches of the availability commitment in any rolling six months, or any single month below 95%, entitles to terminate without penalty." A vendor that misses every quarter and pays a credit each time has priced your tolerance into the deal. The second is the exclusions cap, since planned maintenance is only legitimate if it is bounded, notified, and outside your business hours rather than the vendor's.

Example 5: A Cloud Uptime SLA, Read the Way a Buyer Should Read It

Cloud SLAs make the best worked example, because the major providers publish theirs in full. Amazon's EC2 commitment, last updated 25 May 2022, is 99.99% monthly uptime at the region level, meaning instances across multiple availability zones, and 99.5% for a single instance. The credit ladder is identical for both.

Put those commitments through the math above. Region-level 99.99% allows 4m 19s in a 30-day month; instance-level 99.5% allows 3h 36m. That is a fiftyfold difference between two numbers on the same page, and it is entirely architecture: run in one zone and you have bought the weaker promise.

AWS also does something worth using as a benchmark elsewhere: it "will not charge you for any Single EC2 Instance that is Unavailable for more than six minutes of a clockhour," and this "applies automatically and you do not need to request credit." Google's Compute Engine SLA commits to 99.99% for instances in multiple zones on the Premium tier and 99.9% for a single instance of most machine families, with a more generous 25% middle band. The catch is the claim: "Customer must notify Google technical support within 60 days from the time Customer becomes eligible to receive a Financial Credit."

So compare measurement definitions before headline numbers, check whether the remedy is automatic or claimed, and translate every percentage into minutes.

Service Credits, and Why They Rarely Cover the Loss

Credits read like compensation and function as a governance signal. Under the AWS SLA they "may be applied only against future payments for Amazon EC2" and "will not entitle you to any refund or other payment from AWS." Google's go to future bills. Both agreements are explicit that this is the whole remedy: AWS "sets forth your sole and exclusive remedies," Google's "states Customer's sole and exclusive remedy."

Now put that against the loss. Uptime Institute's 2026 outage analysis reports that "57% of respondents said their most recent major outage cost more than $100,000" and that "for the second consecutive year, 1 in 5 reported costs exceeding $1 million" (Uptime Institute). A 10% credit against the affected month's charges is a modest discount on the next invoice. The arithmetic isn't meant to balance.

So treat credits as a signal, not insurance. A supplier who won't put a meaningful percentage behind a number doesn't believe it. The real protection lives elsewhere: redundancy, continuity arrangements, and a chronic-failure termination right.

Making an SLA That Survives Contact With Reality

A signed SLA changes nothing on its own. The agreements that hold have four habits behind them.

Name one owner per agreement. Not a committee, a person whose job includes publishing the report and chairing the review. An SLA with no owner degrades quietly, because breaching it costs nobody anything until a renewal.

Put the numbers where the work happens. A target buried in a shared drive is invisible at the moment it matters, which is when someone picks the next ticket. Queue displays and team boards are ordinary visual management, and an SLA nobody can see is an SLA nobody meets.

Escalate on a trigger, not on a mood. Borrow the logic of andon: when a threshold is crossed, a signal fires and a named person responds. A P1 at 50% of its resolution target should page the duty manager whether or not the engineer thinks it's going badly.

Review breaches for causes, not for blame. Run root cause analysis on the recurring ones and test each fix through a PDCA cycle. Standing process monitoring makes that possible, since you cannot review what nobody instrumented. Where the same manual step causes the same delay monthly, workflow automation on intake or routing pays back faster than renegotiating the target, and standardising the process stops one SLA meaning three things in three regions.

How SLAs Become Decorative

Most dead SLAs died the same handful of ways.

• A target nobody measures. If no system produces the number automatically, the number does not exist.
• Exclusions that swallow the commitment. Unlimited maintenance, unbounded "customer-caused delay" and a pause status with no rules gut a 99.9% promise without touching the headline.
• No owner and no review date. Both belong in the signature block, not the appendix.
• Averages instead of percentiles. A mean hides the tail, and the tail generates the complaints.
• Targets copied from a bigger company. A 15-minute P1 response means nothing without an on-call rota.
• A commitment with no back-to-back agreement. A promise that depends on a team which never agreed to anything is a cheque against someone else's account.

Take whichever template fits, fill in the bracketed values, then spend the real effort on the measurement method and the exclusions. Those two clauses decide what the agreement means in the month it first gets tested.