A service level agreement sets out what performance a provider promises, how that performance gets measured, and what the customer gets when it slips. Most free SLA templates hand you a blank uptime percentage and no way to reason about it. This one comes with the numbers filled in around it: what each uptime tier actually allows in downtime, how the measurement definition can quietly undo the number, and why service credits are the weakest remedy in the document. Download it free in Word or PDF.
Free to use. Legally binding under the ESIGN Act, UETA, and eIDAS.Updated September 2026 by Document eSign
A service level agreement is the part of a contract that turns a vague promise of good service into something measurable. It names the service, sets a target such as 99.9% monthly availability or a two-hour response to a critical incident, defines exactly how that target is measured, lists what does not count against it, and says what the customer gets when the target is missed. It is rarely a standalone contract. In most commercial relationships the SLA is an exhibit to a master service agreement, which is where the limitation of liability, indemnities, confidentiality, and governing law live. That split matters more than it sounds: the SLA holds what is promised and how it is measured, and the master agreement holds what happens legally when the promise breaks. Get the split wrong and you end up with a precise metric attached to no meaningful remedy. Two things separate an SLA that works from one that is decoration. The first is the measurement definition, because a generous-looking percentage can be undone by how downtime is counted and by how much maintenance is carved out. The second is the remedy, because service credits, the standard answer, are capped, must usually be claimed, and refund your own money rather than compensating your loss. The clause that actually gives a customer leverage is the right to walk away after repeated failures, and it is missing from most templates.
Who uses it
A SaaS or cloud provider putting an availability commitment in front of an enterprise buyerA managed IT provider or MSP committing to response and resolution timesA customer reviewing a vendor's SLA before signing, who wants to know what to push back onA procurement or vendor management team standardising terms across suppliersAn agency or BPO committing to turnaround or answer-rate targetsAn internal IT team writing the operational agreement that sits behind a customer-facing SLAAnyone whose contract says "commercially reasonable efforts" and wants a number instead
What's inside
A version and underlying-agreement clause, so the SLA cannot be amended out from under you
Definitions of downtime, downtime period, excluded minutes, and monthly uptime percentage
A scope clause naming the covered services, regions, and what is excluded
An availability commitment with a fill-in target
A measurement clause requiring a named monitoring system
A monthly reporting obligation, including proactive outage notification
An exclusions list, with a cap on emergency maintenance
A maintenance clause with a capped window and a notice requirement
Four severity tiers with separate response and restoration targets
A role-based escalation ladder
A tiered service credit schedule with a cap
A credit claim clause that applies credits automatically
A chronic-failure termination right with no early termination charge
Client obligations, governance and review cadence, and a remedies clause with carve-outs
HOW IT WORKS
From template to signed in three steps.
01
Start from the template
Open it in the editor with the fields already mapped, or download the DOCX to edit offline.
02
Add signers and send
Drop signature and date fields, then route each party in order or in parallel.
03
Get a sealed copy
Everyone signs, and you get a tamper-evident PDF plus an audit certificate.
Free forever. No credit card. Your recipients sign with no account.
The details
Everything to know before you send it.
1
How to fill it in
Six fields carry almost all the weight. The rest is structure.
Underlying agreement: say whether this is standalone or an exhibit to a master agreement, and name that agreement. Then date the version, so a later version published by the provider does not silently replace it.
Scope: name the exact services, environments and regions covered. Anything not named is not covered, and beta or trial features should be excluded explicitly.
Availability target: pick it from the downtime table below, not from instinct. Work out what the number allows in minutes before you commit to it.
Measurement: name the actual monitoring system and say who can see the raw data.
Maintenance: cap the hours per month and require advance notice. An uncapped maintenance carve-out is the most common way an uptime promise is quietly cancelled.
Severity tiers: set separate response and restoration targets. A template that only promises response time is promising to pick up the phone, not to fix anything.
Credits and chronic failure: set the credit bands, then set the number of missed months that lets the customer leave. The second one is what gives the first one force.
2
What your uptime number actually allows
Every SLA negotiation starts with a percentage, and almost nobody converts it into time before agreeing to it. The difference between 99.9% and 99.99% sounds like rounding. In practice it is the difference between three quarters of an hour of downtime a month and four minutes. These figures assume a 30-day month of 43,200 minutes and a 365-day year of 525,600 minutes. Real SLAs usually measure per calendar month, so the allowance shifts slightly between a 28-day and a 31-day month.
99% allows 7 hours 12 minutes per 30-day month, and 3 days 15 hours 36 minutes per year.
99.5% allows 3 hours 36 minutes per month, and 1 day 19 hours 48 minutes per year.
99.9%, the common commercial default, allows 43 minutes 12 seconds per month, and 8 hours 45 minutes 36 seconds per year.
99.95% allows 21 minutes 36 seconds per month, and 4 hours 22 minutes 48 seconds per year.
99.99% allows 4 minutes 19 seconds per month, and 52 minutes 34 seconds per year.
99.999% allows 25.9 seconds per month, and 5 minutes 15 seconds per year.
The practical read: 99.9% is a serious commitment for a small team, since a single bad deploy can consume the entire month's allowance. 99.99% requires redundancy that costs real money. Promise the tier you can actually hold, because a missed target you set yourself is worse than a lower one you meet.
3
SLA, MSA, SOW and OLA: which document holds what
These four get used interchangeably and they should not be. Getting the split right is the difference between a measurable promise with consequences and a number floating in a document nobody can enforce.
The MASTER SERVICE AGREEMENT holds the terms that span the whole relationship: limitation of liability, indemnities, IP ownership, confidentiality, data protection, termination and governing law. It is signed first and sets the legal frame.
The STATEMENT OF WORK holds one project: deliverables, milestones, acceptance criteria, price and named personnel. There is usually one per project, sitting under the master agreement.
The SLA holds measurable performance only: availability, response times, support hours, how each is measured, and the remedy when one is missed. It is normally an exhibit to the master agreement rather than a third separate contract, though it can stand alone if it is signed and supported by consideration.
The OPERATIONAL LEVEL AGREEMENT is internal. It is what one team inside the provider commits to another so that the customer-facing SLA is achievable. The customer never signs it. It has to be tighter than the SLA it supports, because the coordination overhead between teams has to fit inside the external promise.
The UNDERPINNING CONTRACT is the mirror image: the provider's own contract with an upstream vendor, which needs to be at least as strong as what the provider promised downstream. If you promise 99.99% on top of a supplier who gives you 99.9%, you have promised something you cannot deliver.
Worth knowing: when a target is internal and carries no financial consequence, it is a service level objective, not an SLA. Good practice is to set the internal objective tighter than the contractual commitment, so engineering gets paged well before lawyers get involved.
4
How availability gets measured, and why the definition beats the number
The measurement clause decides what the percentage is worth, and it is where the real negotiation happens. Google Cloud's Compute Engine SLA shows how much work a definition does. It defines a Downtime Period as "a period of one or more consecutive minutes of Downtime", and then adds that "partial minutes or intermittent Downtime for a period of less than one minute will not count towards any Downtime Periods". Read that carefully. Under that definition, a service that failed for 59 seconds out of every minute, continuously, would still report 100% uptime. That is not a criticism of Google, whose wording is clear and standard. It is the point: the same 99.9% means very different things depending on the sentence next to it.
Measurement window: a calendar month resets the count, which lets a single long incident be split across two months and dilute both. A rolling 30-day window is harder to game.
Who measures: provider self-reporting from its own console is the single biggest source of credit disputes. Name the monitoring system in the contract and say who can see the raw data.
What counts as down: total unavailability only, or also degraded performance and elevated error rates? Most templates cover only total unavailability, which means a service that is up but returning errors on half its requests is technically meeting its SLA.
Minimum outage duration: a floor such as five consecutive minutes stops every blip becoming a credit event, which is reasonable. It also makes short repeated failures invisible. Know which way it cuts for your workload.
Scope of measurement: per region, per instance, or per account. A regional average can hide a total outage for the customers in one region.
Who reports the miss: if the customer has to notice and report the downtime, the customer is doing the provider's monitoring. This template requires the provider to report proactively.
5
The exclusions that quietly cancel your uptime promise
Exclusions are the clause where an impressive percentage goes to die, and the arithmetic is worth doing explicitly. Suppose a provider commits to 99.9% availability, which allows 43 minutes 12 seconds of downtime in a 30-day month. Now suppose the same agreement permits four hours of scheduled maintenance per month, excluded from the calculation. Four hours is not this template's default, which leaves the cap blank for you to set. It is simply a common figure, and a useful one to run the numbers on. Four hours is 240 minutes, which is 0.556% of the month. That single carve-out is more than five times larger than the entire downtime allowance the percentage appeared to give you. The number says 99.9%. The document delivers something closer to 99.3%, and it is not a trick, it is just two clauses that most readers never compare. Exclusions are legitimate and every real SLA has them. The question is whether each one is capped.
Scheduled maintenance: accept it, but cap the hours per month, fix the window to off-peak, and require several days notice. Uncapped is the same as no SLA.
Emergency maintenance: the widest loophole in most templates, because anything can be called an emergency. Cap it in hours per month, as this template does.
Customer-caused issues and customer equipment: reasonable, and standard. AWS excludes downtime "that result from your equipment, software or other technology", which is fair enough.
Force majeure and upstream failures: standard, but watch the boundary. AWS excludes problems "beyond the demarcation point", so know where your provider's responsibility ends.
Beta, trial and pre-release features: always excluded, and reasonably so. Just make sure nothing you depend on in production is quietly classified as beta.
Suspension for non-payment or policy breach: standard, but it should require notice first.
The clause to add: require the provider to identify every excluded minute in the monthly report, with a reason. Minutes not identified count as downtime. Without that, exclusions are claimed retrospectively to explain away a miss.
6
Service credits, and why they are the weakest part of the document
Service credits are the standard remedy and they are worth far less than they look. AWS states the mechanics plainly in its own Compute SLA, which is the clearest short explanation of the problem you will find. Credits must be claimed, not paid automatically: the customer opens a support case, and "your credit request must be received by us by the end of the second billing cycle after which the incident occurred". The customer carries the burden of proof, supplying "your request logs that document the errors and corroborate your claimed outage". And the credit is not money: "We will apply any Service Credits only against future payments... Service Credits will not entitle you to any refund or other payment from AWS." Add the cap, usually at one month of fees for the affected service, and the shape becomes clear. An outage that costs a customer fifty times the monthly fee produces, at most, one month of that fee back, in the form of a discount on the next invoice, and only if the customer noticed, claimed in time, and proved it.
Make credits automatic. If the provider is already measuring and reporting under the SLA, it can apply the credit itself. This template does that, and it removes the most common reason credits go unpaid.
Check the claim window. A short window combined with a customer who has to spot the outage themselves is a credit that will rarely be paid.
Watch for earn-back clauses, which let the provider recover a credit by hitting the target for some period afterwards. They are not automatically unreasonable, but know if one is there.
Read the cap against your actual exposure, not against the fee. The fee is what the provider is risking. Your loss is a different number entirely.
Treat credits as a signal rather than compensation. Their real value is that they make failures visible and expensive enough to notice internally at the provider.
The remedy that matters is in the next section.
7
The remedy with teeth: termination for chronic failure
If service credits are the only remedy, a provider that misses the target every single month is entitled to keep missing it forever, so long as it keeps issuing credits. The customer receives a small discount and remains locked in. This is the single biggest gap in free SLA templates, and it is the clause worth spending your negotiating capital on. Telecoms contracts, which have had SLAs longer than software has, tend to handle it properly. Verizon's Ethernet Virtual Private Line service guide sets escalating credits for consecutive months of failure, 25% of the monthly recurring charge for one month and 50% for a second consecutive month. At three consecutive months the customer chooses: either a credit of 100% of the monthly recurring charge for the third month and every consecutive month after it, or the right to terminate that circuit without incurring termination liability, on written notice within 30 days. Note that it is a choice between the two, not both. That is a real remedy, because it restores the customer's ability to leave.
Define chronic failure by count, not by feel: N missed months in a rolling M-month window, or any single month below a floor percentage.
Make termination penalty-free. A right to leave that costs an early termination charge is not really a right to leave.
Include a refund of prepaid fees for the unused period, and a defined transition assistance period. Data extraction help matters more than the refund.
Make sure the sole-remedy clause carves this out. If credits are the only remedy for everything, the termination right you just negotiated may be unenforceable.
For the provider's side: this clause is not as one-sided as it looks. A capped, defined exit is far better than an argument about material breach, and it is a strong signal to buyers that you expect to meet your targets.
8
Are service credits a penalty? The liquidated damages question
This comes up whenever the credits are large, and it is worth understanding before you set the numbers. US contract law does not let parties agree to punish each other. Under the Restatement (Second) of Contracts section 356, damages may be fixed in advance "but only at an amount that is reasonable in the light of the anticipated or actual loss caused by the breach and the difficulties of proof of loss", and a term fixing unreasonably large liquidated damages "is unenforceable on grounds of public policy as a penalty". The Uniform Commercial Code applies the same unreasonably-large test where it governs. So the working test has two parts: was the loss genuinely hard to estimate when you signed, and is the agreed amount proportionate to the anticipated harm? Fail either and a court may treat the clause as an unenforceable penalty. In practice most vendor-drafted credit clauses avoid this problem by being far smaller than the customer's likely loss, and by being framed as a price adjustment rather than as damages. Whether US courts generally treat service credits as liquidated damages is not settled, and there is remarkably little reported US case law on cloud uptime disputes, so treat this as a drafting consideration rather than a rule.
Set credits by reference to anticipated harm, and keep a note of your reasoning. That note is the evidence that the figure was a genuine estimate.
Keep the cap. A capped credit is much harder to characterise as punitive.
Do not draft credits as a deterrent. Describing them as a penalty in the document itself is an unforced error.
If your agreement is governed by English law, the test is different. Since Cavendish Square Holding BV v Talal El Makdessi and ParkingEye Ltd v Beavis in 2015, the English question is whether the clause imposes a detriment out of all proportion to the innocent party's legitimate interest in performance, rather than whether it is a genuine pre-estimate of loss. Interests beyond pure compensation can count.
Sole-remedy clauses have limits too. They are generally enforced between commercial parties, but they are read narrowly against the party relying on them, and they typically will not shield gross negligence or willful misconduct. Carve those out explicitly rather than assuming.
9
How this differs by sector
The structure of this template holds across sectors, but which metric carries the weight changes a lot.
SaaS and cloud: availability is the headline, measured as a monthly uptime percentage, with credits capped at a share of monthly fees. Worth knowing how much variation there is at the top end. Salesforce's Main Services Agreement, last updated 1 June 2026, commits only to "commercially reasonable efforts" to keep the purchased services available, with no percentage and no credits anywhere in the document, while MuleSoft, which Salesforce owns, publishes 99.95% with a 5, 10 and 15% credit ladder. One of the largest enterprise software vendors in the world gives most customers no numeric uptime guarantee at all unless they negotiate for one.
Managed IT and MSPs: response and resolution by severity tier matter far more than uptime, and coverage hours plus clock-pausing rules matter more than either. Remedies are usually a share of the monthly management fee.
Telecoms: availability plus mean time to repair, credits as a percentage of the monthly recurring charge, escalating for consecutive failures, with termination rights on chronic failure. Check what MTTR is defined as, since it sometimes means time to first contact rather than time to service restored.
BPO and contact centres: the metric is a share of contacts answered within a target time, often quoted as 80% within 20 seconds. The definition does the work here too. Whether abandoned calls sit in the denominator, and whether the target applies per interval or per month, changes what the same number means.
Internal IT: no money changes hands, so credits are meaningless. The currency is escalation, reporting, and budget consequences, and the internal agreement has to be tighter than the external SLA it supports.
Regulated customers: if your customer is an EU financial entity, the EU's Digital Operational Resilience Act has applied since 17 January 2025 and requires contracts covering critical or important functions to carry precise quantitative and qualitative performance targets. A vague SLA is a compliance problem for them, not just a commercial weakness. Separately, the EU Data Act's cloud switching rules have applied since 12 September 2025 and reach providers outside the EU who serve EU customers.
10
If you are the provider, not the customer
Most of the advice above is written from the customer's chair, because that is who usually arrives at a page like this and because vendor-drafted SLAs are where the one-sided clauses live. If you are the one drafting the SLA, the same clauses look different, and several of the customer-friendly positions are ones you can concede cheaply in exchange for something that matters more to you. Here is the other side of each.
Commit to a target you can hold on your worst month, not your average one. Buyers respect 99.5% that never slips far more than 99.99% missed twice a year, and a target you miss repeatedly triggers every other clause in the document.
Automatic credits cost you less than they look. You are already measuring and reporting, so applying the credit yourself is a small operational step, and it removes the dispute, the support ticket, and the argument about whose logs are right. It also reads as confidence to a buyer.
Cap what you can genuinely control, and say why. A cap on emergency maintenance is reasonable to agree, but ask for the right to exceed it where a security patch demands it, with notice and a report afterwards. Buyers accept that when it is framed honestly.
Push back on measurement scope rather than on the percentage. Per-region measurement, a minimum outage duration, and a clear definition of what counts as down protect you far more than an extra decimal place, and they are easier to justify.
Ask for reciprocal obligations. If the customer must report incidents through a named channel for the clock to start, if the clock pauses while you wait on them, and if their own misconfiguration is excluded, say so explicitly. This template includes those, and they are not unreasonable to insist on.
Bound the chronic-failure exit. A termination right is easier to grant when it is defined by count, limited to the affected service rather than the whole contract, and requires written notice within a set window. An unbounded right to walk on any dispute is a different thing entirely, and you should not agree to it.
Keep the sole-remedy clause, but carve out the right things. Trying to cap liability for gross negligence, willful misconduct or a security breach tends to fail anyway, and asking for it costs you credibility in a negotiation you could otherwise win.
11
Common mistakes to avoid
SLAs fail in predictable ways, and almost all of them are drafting problems rather than engineering ones.
Setting the target from ambition rather than from data. Look at six to twelve months of your own monitoring before you commit to a number.
Defining the percentage but not the measurement, so there is no window, no named measurer, and no definition of what counts as down.
Letting the provider measure with an unnamed tool and report on itself.
Leaving maintenance uncapped, which cancels the commitment arithmetically.
Promising response time and staying silent on restoration.
Writing credits that require a claim the customer will never know to make.
Making credits the sole remedy with no carve-outs for gross negligence, willful misconduct, or a security breach.
Omitting a termination right for chronic failure, which leaves the customer collecting small discounts indefinitely.
Using "best effort", "as soon as possible" and "commercially reasonable" where a number belongs.
Measuring activity rather than outcome. Delivering 100,000 API responses per day is met even if none of them are correct.
Leaving "business hours", "critical" and "available" undefined.
Signing an SLA the provider can amend unilaterally. Pin the version by date, as this template does.
Forgetting the customer's own obligations, such as reporting through a named channel, which is what starts the clock.
This template and the guidance on this page are provided for general information only and are not legal advice. Laws differ by country and state, so review the final document against your own situation and have a qualified lawyer check anything high-value or regulated before you sign.
FAQ
Questions, answered.
What is a service level agreement?
A service level agreement is the part of a contract that sets measurable performance standards for a service, defines how those standards are measured, and states what the customer gets when one is missed. Typical standards are availability, expressed as a monthly uptime percentage, and support response and restoration times by severity. It is usually an exhibit to a master service agreement rather than a standalone contract.
What does 99.9% uptime actually allow?
43 minutes and 12 seconds of downtime in a 30-day month, and 8 hours 45 minutes and 36 seconds across a year. For comparison, 99.99% allows 4 minutes 19 seconds a month, and 99% allows 7 hours 12 minutes. Convert the percentage into minutes before you agree to it, because the gap between tiers is much larger than it looks.
What is the difference between an SLA, an MSA and an SOW?
The master service agreement holds the legal terms that span the relationship: liability, indemnities, IP, confidentiality and governing law. The statement of work holds one project's deliverables, milestones and price. The SLA holds measurable performance only, plus how it is measured and the remedy for a miss. The SLA says what is promised; the master agreement says what happens legally when the promise breaks.
Is a service level agreement legally binding?
Yes, where it is signed with consideration or incorporated into a contract that is. Most SLAs are enforceable as part of the master agreement they are attached to rather than in their own right. Watch for two things that weaken enforceability in practice: a sole-remedy clause that caps recovery at a small credit, and a clause letting the provider amend the SLA unilaterally after signature.
How are service credits calculated?
Usually as a percentage of the monthly fee for the affected service, tiered by how far availability fell below target, and capped at some maximum such as one month of fees. This template uses bands of 10%, 25% and 50% as a starting structure. Those are a drafting suggestion, not an industry standard, so set them against your own anticipated loss rather than copying a number. Do not confuse them with the Verizon telecom schedule mentioned elsewhere on this page, which is a different structure from a different sector.
Are service credits the only remedy under an SLA?
They are if the SLA says so, and most vendor-drafted SLAs do, through a sole and exclusive remedy clause. That is worth pushing back on. At a minimum, carve out gross negligence, willful misconduct, breach of confidentiality and security obligations, and any indemnity, and make sure a right to terminate for chronic failure sits outside the sole-remedy clause so it remains available.
Can a customer terminate for repeated SLA failures?
Only if the agreement gives that right, and most free templates do not. Without it, a provider can miss the target every month indefinitely and satisfy its obligations by issuing credits. Define chronic failure by a count of missed months in a rolling window, or a floor percentage in any single month, and make termination free of early termination charges. This is the clause that gives the rest of the document force.
Who measures uptime under an SLA?
Whoever the contract names, which is the point of naming one. Where an SLA is silent, the provider measures with its own tooling and reports on itself, and that is where credit disputes start. Say which system measures, whether it checks from more than one location, and who can see the raw data.
What is the difference between an SLA and an OLA?
An SLA is external and signed by the customer. An operational level agreement is internal, between teams inside the provider, and covers the commitments that make the customer-facing SLA achievable. The OLA has to be tighter than the SLA it supports, because the handoffs between internal teams consume part of the time the external promise allows.
Is the service level agreement template available in Word format?
Yes. Download the SLA as a Word (.docx) file, fill in the bracketed fields for your services, targets, credit bands and notice periods, and edit any clause to match your agreement. It opens in Word, Google Docs and Pages.
Can I download the service level agreement as a PDF?
Yes. A PDF version is available alongside the Word file. Use the PDF if you want a clean copy to circulate for review or to sign as-is, and the Word file if you need to edit the targets and clauses first. You can also sign it online here without printing anything.
Live in under a minute
Ready to send your first envelope?
Create your free forever account, upload a document, and send it for signature in minutes. No credit card required.
30 free envelopes a month Legally binding · global Audit trail on every document
