Service Level Agreement Template

Commit to uptime without open-ended risk, covering availability, service credits, and support, adapted for the US, UK, and EU.

Compliance
Adjust for your territory

Sets a starting point for your main market; serving several, enable extra sections under Customize. These adjustments cover the US, UK, and EU broadly and are not a substitute for advice on your specific country's law.

Scroll for section-by-section legal context. Click any purple chip to fill in that field. Switch to Customize to enable optional clauses.

SERVICE LEVEL AGREEMENT

Effective Date: {Effective Date}

Last updated: {Last Updated Date}

1. Acceptance of This Agreement

This Service Level Agreement (the "SLA" or "Agreement") is between {Company Name} ("we", "us", or "our") and the customer that subscribes to or uses the Service ("you" or "your"). It sets out the service levels for {Service Name} and the related features we provide (the "Service"), and it forms part of, and is incorporated by reference into, the broader agreement between us for the Service, such as our Terms of Service or master subscription agreement (the "Agreement").

You accept this SLA by subscribing to, accessing, or using the paid Service, by clicking "I Agree," or by entering into a signed agreement that incorporates it. If you are accepting on behalf of a company or other organization, you represent that you are authorized to bind that organization, in which case "you" and "your" refer to that organization.

About this section

What's in this section

Names the parties, ties the SLA to your main agreement, and records that subscribing to or using the paid Service accepts it.

Why this section is here

An SLA is enforceable because it is part of the contract the customer accepted. Incorporating it into your Terms of Service or master agreement, and tying acceptance to an affirmative act, keeps the uptime promise binding rather than a marketing claim.

Common mistake

Publishing the SLA as a standalone web page no agreement references, so neither side is actually bound by it.

Electronic acceptance under ESIGN →

2. Definitions

For the purposes of this SLA:

  • "Service" means {Service Name} and the related features we provide under the Agreement.
  • "Available" means the Service is accessible and operating materially in accordance with its documentation, and "Availability" is construed accordingly.
  • "Downtime" means any period, measured in minutes, during which the Service is not Available, other than the periods excluded under Section 5.
  • "Monthly Uptime Percentage" means, for a given {Measurement Period}, the total number of minutes in that period minus Downtime, divided by the total number of minutes in that period, expressed as a percentage.
  • "Scheduled Maintenance" means maintenance for which we give advance notice as described in Section 10.
  • "Emergency Maintenance" means urgent maintenance needed to protect the security, integrity, or availability of the Service.
  • "Service Credit" means a credit calculated under Section 6.
  • "Severity Level" means the priority assigned to a support request as described in Section 9.
About this section

What's in this section

The shorthand the rest of the SLA relies on: Service, Availability, Downtime, Monthly Uptime Percentage, Scheduled and Emergency Maintenance, Service Credit, and Severity Level.

Why this section is here

An SLA lives or dies on its definitions. Whether a given outage counts depends entirely on how 'Available' and 'Downtime' are defined, so fixing them once keeps the commitment and the exclusions precise.

Common mistake

Leaving 'Available' vague, which turns every incident into an argument about whether the Service was really down.

3. Service Availability Commitment

We will use commercially reasonable efforts to make the Service Available at least {Uptime Commitment} of the time during each {Measurement Period} (the "Service Commitment").

The Service Commitment applies only to the production Service on paid plans. It does not apply to free, trial, beta, evaluation, or preview features or plans, which are provided "as is" and without any availability commitment. (Set the commitment to a level your infrastructure can sustain; the credits you owe scale with how often you miss it.)

About this section

What's in this section

The headline promise: the uptime percentage you commit to over each measurement period, and which plans it covers.

Why this section is here

This is the number customers buy on and hold you to. Stating it as a commitment, scoped to paid production use, is what makes the SLA real without over-promising on free or beta tiers.

Common mistake

Promising more uptime than your architecture can deliver. The credits you owe are only as affordable as the target is realistic.

4. Measuring Availability

We measure Availability using our own monitoring systems and records, which are the authoritative source for calculating the Monthly Uptime Percentage, unless you provide reasonable evidence to the contrary. Downtime is measured from the time the Service first becomes unavailable, as recorded by our systems or a valid support ticket you open, until Availability is restored.

The periods listed in Section 5 are excluded from Downtime and from the total minutes used in the calculation. (If you let customers rely on a third-party monitoring tool, state whether and how its readings are reconciled with your own.)

About this section

What's in this section

How uptime is calculated, whose monitoring is authoritative, and that excluded periods come out of the maths.

Why this section is here

If you do not say how uptime is measured and whose data counts, every credit claim becomes a dispute about measurement. Naming your monitoring as the source of record settles that.

Common mistake

Staying silent on measurement, then arguing with customers who point to a third-party status tracker that disagrees with your own.

5. Exclusions from Downtime

The following are not counted as Downtime and do not entitle you to a Service Credit:

  • Scheduled Maintenance and Emergency Maintenance;
  • factors outside our reasonable control, including force majeure events and failures of the internet, networks, or infrastructure not operated by us;
  • your equipment, software, connectivity, or configuration, or any act or omission by you or your users, including misuse or use not permitted by the Agreement or the documentation;
  • suspension or termination of the Service for your breach of the Agreement or non-payment, or as otherwise permitted by the Agreement;
  • problems caused by third-party services, hardware, or software we do not provide or control;
  • beta, trial, free, evaluation, or preview features; and
  • denial-of-service or other attacks, or security incidents, not resulting from our failure to meet our obligations.
About this section

What's in this section

The outages that do not count toward Downtime: maintenance, force majeure, customer-caused issues, third-party failures, and beta features.

Why this section is here

Exclusions are what keep the commitment achievable. You cannot owe credits for an ISP outage, a customer misconfiguration, or a DDoS attack, so the SLA has to carve those out explicitly.

Common mistake

Vague or missing exclusions, which leave you owing credits for downtime you neither caused nor could prevent.

6. Service Credits

If the Monthly Uptime Percentage for the Service in a {Measurement Period} falls below the Service Commitment, you are entitled to a Service Credit, calculated as a percentage of the fees you paid for the affected Service for that period:

  • below {Uptime Commitment} but at or above 99.0%: a 10% Service Credit;
  • below 99.0% but at or above 95.0%: a 25% Service Credit;
  • below 95.0%: a 50% Service Credit.

(Adjust the tiers and percentages to match your Service Commitment and pricing.)

A Service Credit is applied against your future fees for the Service, has no cash value, and is not refundable. The total Service Credits we owe for any single {Measurement Period} will not exceed the total fees payable for the affected Service in that period.

About this section

What's in this section

The remedy: a tiered schedule of credits, as a percentage of fees, owed when uptime falls below the commitment, plus a cap.

Why this section is here

Credits are the agreed price of missing the target. A clear, capped schedule turns a breach into a predictable, bounded cost instead of an open-ended damages claim.

Common mistake

Leaving the credit amounts or the cap unstated, so a bad month exposes you to an unpredictable liability.

7. Claiming Service Credits

To receive a Service Credit, you must submit a claim to {Email Address} within {Credit Claim Period} after the end of the {Measurement Period} in which the Downtime occurred. Your claim must include the dates and times of the Downtime, the affected Service, and any logs or other evidence reasonably available to you.

We will review your claim against our records and, where we confirm the Service Commitment was not met, apply the Service Credit to a future invoice. If you do not submit a valid claim within the period above, you waive your right to a Service Credit for that {Measurement Period}. You must be current on all amounts due under the Agreement to be eligible for a Service Credit.

About this section

What's in this section

How and when a customer must claim a credit, what evidence to include, and that credits apply to future invoices rather than cash.

Why this section is here

A claim window and a process give you a defined period to verify outages against your records and stop stale or speculative claims. It is also what makes credits administrable at scale.

Common mistake

No claim deadline, so customers can reach back months later, and no statement that credits are not refunds, inviting cash demands.

8. Sole Remedy and Limitation of Liability

Except as set out in the territory-specific terms below, Service Credits are your sole and exclusive remedy, and our entire liability, for any failure to meet the Service Commitment or any unavailability of the Service. (Set {Liability Cap} and the governing law below to match the cap and law in your main agreement.)

United States. To the fullest extent permitted by law, Service Credits are your sole and exclusive remedy for any failure to meet the Service Commitment. Except for our obligation to issue Service Credits, in no event will {Company Name} or its suppliers be liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for any loss of profits, revenue, data, business, or goodwill, however caused and on any theory of liability, even if advised of the possibility; and our total aggregate liability arising out of or relating to the Service or this Agreement will not exceed {Liability Cap}. These limitations apply even if a remedy fails of its essential purpose.

About this section

What's in this section

States that Service Credits are the sole and exclusive remedy for missed uptime, and caps liability. The wording swaps by territory.

Why this section is here

Making credits the sole remedy is the whole point of an SLA: it converts uptime risk into a fixed, capped credit instead of damages. US law allows this broadly; the UK applies a reasonableness test and the EU keeps mandatory carve-outs for death, personal injury, and fraud.

Common mistake

A blanket sole-remedy and exclusion clause used unchanged in the UK or EU, where the non-excludable carve-outs must remain.

9. Support and Response Times

We provide support for the Service through {Email Address} and any other channels we publish from time to time. (Replace with your actual channels, support hours, and tiers — for example, business days 9:00 to 18:00 local time excluding public holidays, or 24/7 for Severity 1 incidents.) We classify support requests by Severity Level and use commercially reasonable efforts to meet the following target response times during your support hours:

  • Severity 1 — Critical: the Service is down or unusable for all users, with no workaround. Target response within 1 hour.
  • Severity 2 — High: a major feature is impaired with no reasonable workaround. Target response within 4 hours.
  • Severity 3 — Normal: a minor or partial issue, or one with a workaround. Target response within 1 business day.
  • Severity 4 — Low: questions, guidance, and feature requests. Target response within 2 business days.

Response times are targets, not guarantees, and do not carry Service Credits unless we expressly state otherwise. Support does not cover issues excluded under Section 5.

About this section

What's in this section

Support channels, severity levels, and target response times. These are targets, not credit-backed guarantees, unless you say otherwise.

Why this section is here

Buyers, especially enterprise ones, treat support responsiveness as part of the service level. Defining severity levels and target response times sets expectations without creating a second credit obligation.

Common mistake

Promising response or resolution times as hard guarantees, which quietly creates a second SLA you may not be able to meet.

10. Scheduled Maintenance

We may perform Scheduled Maintenance to keep the Service secure, reliable, and up to date. We will give at least {Maintenance Notice} advance notice of Scheduled Maintenance that we expect to cause Downtime, and we will use reasonable efforts to perform it outside peak hours.

We may perform Emergency Maintenance at any time, without advance notice, where it is needed to protect the security, integrity, or availability of the Service. We will use reasonable efforts to limit its scope and duration and to notify you as soon as reasonably practicable. Scheduled Maintenance and Emergency Maintenance are excluded from Downtime under Section 5.

About this section

What's in this section

Your right to take the Service down for maintenance, the notice you give, and faster emergency maintenance, all excluded from Downtime.

Why this section is here

Every service needs maintenance windows. Reserving them with advance notice, and a no-notice path for emergencies, is what lets you patch and secure the Service without breaching your own uptime promise.

Common mistake

No reserved maintenance window, so planned upgrades count as Downtime and trigger credits.

11. Term and Changes

This Agreement applies for as long as you subscribe to or use the Service and forms part of the Agreement between us. We may update this SLA from time to time to reflect changes to the Service, our infrastructure, or the law. When we make material changes, we will give reasonable notice, such as by updating the "Last updated" date above, posting the new version with the Service, or sending you notice, and changes take effect on a going-forward basis for the {Measurement Period} after they are posted. Your continued use of the Service after the changes take effect constitutes acceptance.

About this section

What's in this section

That the SLA runs while the customer subscribes and forms part of the main agreement, and how you update it going forward.

Why this section is here

Service levels change as your infrastructure does. Tying the SLA to the subscription and updating it prospectively lets you adjust commitments without rewriting the whole contract.

Common mistake

Treating silent edits as binding for past periods, or detaching the SLA from the agreement it is supposed to support.

12. Governing Law and Disputes

Informal resolution. Before bringing a formal claim, you agree to contact us at {Email Address} and give us a reasonable opportunity to resolve the matter informally.

Governing law and courts. This Agreement is governed by the laws of {Governing Law}, without regard to its conflict-of-laws rules, and you and we submit to the exclusive jurisdiction of {Jurisdiction}.

About this section

What's in this section

Which law applies, where disputes are heard, and an informal-resolution step before any formal claim.

Why this section is here

Choice of law and forum decide how a credit or liability dispute runs. Setting them, with a contact-us-first step, keeps most issues out of court.

Common mistake

Leaving governing law unstated, so an outage dispute with a customer in another country has no agreed forum.

13. General

Relationship to the Agreement. This SLA forms part of the Agreement between you and us for the Service. If there is a conflict between this SLA and the rest of the Agreement on a question of service levels, Service Credits, or availability, this SLA controls; on all other matters, the rest of the Agreement controls.

Entire agreement. This SLA, together with the Agreement it forms part of, is the entire agreement between you and us on service levels and supersedes all prior discussions on the same subject.

Severability. If any provision of this SLA is held to be unenforceable, the remaining provisions remain in full force, and the unenforceable provision will be applied to the maximum extent permitted by law.

No waiver. Our failure to enforce any provision is not a waiver of our right to enforce it later, and issuing a Service Credit is not an admission of liability beyond this SLA.

Assignment. You may not assign or transfer this SLA without our prior written consent. We may assign it in connection with a merger, acquisition, reorganization, or sale of assets.

Notices. We may give you notices by email, through the Service, or by posting them in connection with the Service. You may send us claims and legal notices at {Email Address} or {Mailing Address}.

About this section

What's in this section

Boilerplate and the link to your main agreement: precedence on service levels, entire agreement, severability, assignment, notices, and no waiver.

Why this section is here

Because the SLA sits inside a larger contract, it needs to say how it interacts with it (which controls on service levels) and carry the standard clauses that keep it coherent if one provision fails.

Common mistake

No precedence clause, so it is unclear whether the SLA or the main agreement governs when they appear to conflict on uptime.

14. Contact Us

If you have questions about this SLA or need to submit a Service Credit claim, contact us at:

{Company Name}

{Mailing Address}

Email: {Email Address}

About this section

What's in this section

Your name and contact details, where credit claims, support requests, and formal notices are sent.

Why this section is here

Credit claims and notices need a monitored destination. A clear contact point is what makes the claim process and the notice provisions actually work.

Common mistake

Listing only an unmonitored inbox, so claims and notices go unanswered and deadlines are missed.

Got what you need? Copy the template now, or read on for the section-by-section guide to what each clause does and how to adapt it.

What Is a Service Level Agreement?

A service level agreement (SLA) is the part of a service contract where the provider commits to a measurable standard of service, most often uptime or availability, and states what the customer gets if the provider falls short, usually service credits. It turns a vague "we will keep it running" into a defined, enforceable promise with a fixed consequence for missing it.

An SLA has three linked parts, and they only work together: the commitment (the target, such as 99.9% uptime over each month), the measurement (how uptime is calculated and which periods are excluded), and the remedy (the service credits owed when the target is missed). It does not stand alone. An SLA sits inside a broader contract, normally a Terms of Service or master subscription agreement, and is accepted with it, so the remedy it gives is a contractual one rather than a separate damages claim.

Who Needs a Service Level Agreement?

Any provider whose customers depend on the service being up benefits from a clear SLA, and business buyers increasingly demand one before they sign. The most common cases:

  • SaaS Platform

    Hosted software that promises a measurable level of availability to paying customers.

  • Enterprise & B2B

    Vendors whose business customers require committed uptime and support in procurement.

  • Hosting & Infrastructure

    Hosting, IaaS, and PaaS providers committing to availability of shared or dedicated infrastructure.

  • API / Developer Platform

    API and developer platforms that promise uptime and response times to the apps built on them.

An SLA also works in your favour: a well-drafted one caps your exposure to a known credit instead of leaving you open to a damages claim every time there is an outage. Presented and accepted as part of your agreement through a clickwrap agreement, it binds every customer on the same terms without a separate signature.

How to Make Your Service Level Agreement Binding

This template is designed to be incorporated into your main agreement and accepted by clickwrap at signup. Under the US ESIGN Act and UETA, and under eIDAS in the EU and UK, that acceptance is equivalent to a signature.

Define the metric before the promise. The most-disputed part of any SLA is not the percentage but what counts as Downtime and how it is measured. Pin down "Available," name your monitoring as the source of record, and list the exclusions, so a credit claim turns on the agreed definition, not an argument.

Make credits the agreed remedy, with a process. State that Service Credits are the sole and exclusive remedy for missed uptime, set a capped tier schedule, and give a claim window. That is what converts an outage into a predictable cost rather than an open-ended liability.

Tie it to the accepted agreement and capture the version. Incorporate the SLA into your Terms of Service or subscription agreement, present it before acceptance, and record the version and timestamp each customer accepted, so you can prove which service levels applied in a given period.

Re-present material changes. When you change the commitment, the credit tiers, or the exclusions, give notice and apply the new version going forward. Continued use under a stale version is a weak consent signal.

Negotiated enterprise SLAs are often signed rather than clicked; enable the Signature blocks section for those. The legal substance is the same, only the acceptance mechanism differs.

Frequently Asked Questions

Match the number to what your architecture can actually deliver, then commit slightly below it. 99.9% ("three nines") is the common baseline and allows about 43 minutes of downtime per month; 99.99% allows about 4 minutes and is hard to hit without redundant, multi-region infrastructure. Promising more uptime than you can sustain just means paying out more Service Credits. Set the commitment, the exclusions, and the credit tiers together so a realistic bad month stays affordable.
In most SLAs, yes. The standard structure makes Service Credits the sole and exclusive remedy for failing to meet the uptime commitment, which converts an open-ended damages risk into a fixed, capped credit. That works broadly in the US. In the UK it is subject to the reasonableness test under the Unfair Contract Terms Act 1977, and in both the UK and EU you can never exclude liability for death or personal injury caused by negligence, or for fraud. Use the territory selector to switch the sole-remedy and liability wording.
Yes, when it is incorporated into an agreement the customer accepted and presented properly. An SLA is usually part of your Terms of Service or a master subscription agreement, accepted by clicking "I agree" at signup. Under the US ESIGN Act and UETA, and under eIDAS in the EU and UK, that acceptance is equivalent to a signature. Capture the version the customer accepted and the timestamp so you can prove the service levels in force for a given period.
Usually not, and the template is written that way. Service Credits are calculated as a percentage of the fees paid for the affected Service, so there is nothing to credit on a free plan, and beta, trial, and evaluation features are excluded from the uptime commitment because they are not yet production-ready. State this clearly so a free or beta user cannot claim credits for downtime on a tier that was never covered.

Not legal advice

This template is provided for informational purposes only and does not constitute legal advice. Review and adapt it to your specific situation, and consult a qualified attorney before relying on it for a real-world filing or transaction.

Make your service level agreement enforceable.

ClickTerm captures acceptance of your service level agreement with timestamps, version history, and audit-ready records, so the document holds up when it matters.