Service Level Agreement
Uptime target, response times, support hours and service credits.
Details
service level agreementUploads
Your logo
A photo or picture
Goes on this page only. Drag it anywhere and pull its corner to resize it.
Your signature
Draw it with a finger, a mouse or a trackpad, and it goes on the page like a picture.
Pictures and signatures stay on this device. Nothing is uploaded to a server.
Red highlights mark what is still blank. Click anything on the page to change it. Your draft is kept on this device as you work.
Once it is filled in it still has to be signed. An e-signature service gets it signed and timestamped without anyone printing or scanning.
This Agreement is made on October 14, 2026 between [provider] of [address] (the Provider), and [customer] of [address] (the Customer).
1. Services covered
[describe the services]
2. Support hours
Support is available [hours]. Requests received outside those hours are treated as received at the start of the next support period.
3. Availability
The Provider will use reasonable endeavours to keep the services available at least [percentage]% of the time each calendar month, measured excluding scheduled maintenance notified at least five working days in advance, and excluding failures caused by the Customer, by third-party networks, or by events outside the Provider’s reasonable control.
4. Response times
| Severity | Response time |
|---|---|
| [add severities] |
Response time means the time to acknowledge and begin work on a properly logged request. It is not a commitment to resolve within that time.
5. Review and governing law
The parties will review these service levels annually. This Agreement is governed by the law of [jurisdiction].
What is a Service Level Agreement?
A service level agreement states the level of service a customer can expect, how it is measured, and what happens when it is missed. It converts a vague promise of reliability into numbers with a method behind them: an availability target, response times by severity, support hours and a credit if the target is missed. Without one, an outage becomes an argument about whether the service was ever supposed to be up.
Software vendors and hosting providers attach an SLA to a subscription contract; managed service providers and IT support firms issue one per customer; internal IT and shared service teams publish them to the rest of the business as an operating level agreement. Procurement teams read them closely, because the credits and termination rights are the only real leverage a customer has after signing. Facilities, logistics and outsourcing contracts use the same structure with different metrics — first-time fix rate, on-time delivery, call abandonment.
The SLA sits inside the main contract and inherits its governing law, so what you can promise and what you can limit depends on that jurisdiction. Consumer protection rules restrict exclusions where the customer is an individual. Regulated sectors add obligations on top: financial services outsourcing rules in the UK, EU and India carry expectations about exit plans and continuity, and public sector procurement frameworks often prescribe their own structure. Where personal data is involved, breach notification timings under the applicable privacy law interact with your incident response commitments.
An SLA is not an uptime guarantee and does not make outages impossible. It is a commercial allocation of the consequence — usually a service credit calculated as a percentage of the monthly fee, and usually stated to be the customer's sole remedy. That last phrase is the one to read, because it can exclude claims for the actual loss an outage caused. It is also not a security or compliance document, and it will not cover events outside the provider's control unless you say so.
What to put in a Service Level Agreement
These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.
| Field | What goes in it |
|---|---|
| First party | For example: Barton Supply Co. |
| First party address | For example: Unit 7, Barton Road, Columbus, OH 43212 |
| Second party | For example: Halliwell Interiors Inc. |
| Second party address | For example: 44 High Street, Columbus, OH 43215 |
| Services covered | For example: Hosting, monitoring and maintenance of the customer website and its supporting database. |
| Support hours | For example: 09:00 to 17:30, Monday to Friday, excluding public holidays |
| Uptime target % | For example: 99.5 |
| Response times | One per line: Severity | Response time |
| Service credits optional | One per line: Shortfall | Credit |
| Governing law | For example: England and Wales |
How to write a Service Level Agreement
Define availability and how it is measured
Write the formula, not just the number. State the measurement period, usually a calendar month, what counts as downtime, from which monitoring point it is measured, and how partial degradation is treated. A target of ninety-nine point nine per cent measured monthly from external synthetic checks at five-minute intervals, excluding scheduled maintenance, can be tested. A promise of high availability cannot.
Set severity levels with response targets
Define severity by business impact rather than by technical cause: total loss of service, a major function unavailable with no workaround, degraded performance, cosmetic. Give each level a response target and, where you can commit to one, a resolution or workaround target. Say who assigns severity and how a customer escalates a disagreement, since severity assignment is where most SLA disputes actually begin.
State support hours and the escalation path
Give the hours in a named time zone, say which days are excluded, and list the public holidays that apply or point to the calendar you follow. Name the contact channels in priority order and say which ones start the response clock — an email sent at midnight often does not. Then set out the escalation ladder with roles and target times at each rung.
Set credits, caps and the claim process
Show the credit as a table: performance band against percentage of the monthly fee. State the monthly cap, whether credits are the sole remedy, and whether a sustained pattern of misses creates a right to terminate. Then the process — the customer must claim within a stated number of days, in writing, quoting incident references. If credits are applied automatically, say so explicitly rather than leaving it implied.
List exclusions and the review cycle
Carve out scheduled maintenance with its notice period and window, emergency maintenance, force majeure, failures in the customer's own network or third-party services outside your control, and misuse. Be specific, because a broad exclusion for third-party failure can swallow a cloud-hosted service entirely. Then set a review cadence, the reporting the customer receives, and how targets may be changed by agreement.
Common mistakes
- Publishing an availability percentage with no measurement method, so the provider measures at the server, the customer measures at the browser, and the two never agree.
- Defining severity by technical component rather than business impact, which leaves a total checkout outage classified as a minor database issue.
- Setting a response target with no resolution or workaround commitment, so a ticket acknowledged in fifteen minutes can then sit untouched for a week within the letter of the agreement.
- Making service credits the sole remedy without the customer noticing, which caps a business-critical outage at a fraction of one month's fee.
- Writing exclusions broad enough to cover any third-party dependency, which turns a measured commitment into a promise with no enforceable content.
Frequently asked questions
What is a good uptime percentage for an SLA?
It depends on what the service does and what the architecture can actually sustain. The useful question is what the number means in minutes: three nines allows roughly three quarters of an hour of downtime a month, four nines allows a few minutes. Commit to a level you can measure and evidence rather than the one that reads best in a proposal, because you will be held to it.
What is the difference between an SLA and a contract?
The contract creates the legal relationship — scope, fees, liability, term, termination. The SLA is a schedule inside it that sets measurable performance targets and the consequence of missing them. The SLA has no independent life: its remedies, caps and governing law all come from the main agreement. Reading one without the other is how customers end up surprised by a liability cap.
Are service credits the only remedy for a missed SLA?
Often the agreement says so, and that clause is the one worth negotiating. Customers usually push for a termination right after repeated or severe failures, and for critical services may seek carve-outs so credits do not cap all recovery. What is achievable depends on bargaining power and on the law of the contract. Read the sole remedy wording before signing, not after an outage.
How is downtime calculated?
By the method the SLA specifies, which is exactly why it must specify one. Common approaches count minutes in the measurement period when a defined health check fails from defined locations, subtract excluded windows, and express the remainder as a percentage. Decide in advance how partial failures and degraded performance count, and agree whose monitoring is authoritative. Without that, one incident produces two different numbers.
Does an SLA cover scheduled maintenance?
Almost always as an exclusion, provided the notice period and window in the agreement are followed. Set both explicitly: how much advance notice, through what channel, how long a window may run and how often. Emergency maintenance is usually excluded too, but define it narrowly and require it to be reported afterwards, otherwise the exclusion can be stretched to cover unplanned outages.
This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.