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.
United Kingdom. Nothing in this Agreement limits or excludes our liability for death or personal injury caused by our negligence, for fraud or fraudulent misrepresentation, or for any other liability that cannot lawfully be limited or excluded. Subject to that, Service Credits are your sole and exclusive remedy for failure to meet the Service Commitment, we exclude all indirect and consequential loss and any loss of profits, revenue, data, or goodwill, and our total liability arising out of or relating to this Agreement is limited to {Liability Cap}. These provisions are subject to the reasonableness test under the Unfair Contract Terms Act 1977.
European Union. Nothing in this Agreement excludes or limits our liability for death or personal injury caused by our negligence, for damage caused intentionally or by gross negligence, for fraud, or for any liability that cannot be excluded or limited under mandatory law. Subject to that, and to the fullest extent permitted by law, Service Credits are your sole and exclusive remedy for failure to meet the Service Commitment, we are not liable for indirect or consequential loss or for any loss of profits, revenue, data, or goodwill, and our total liability arising out of or relating to this Agreement is limited to {Liability Cap}.
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}.
Governing law and courts. This Agreement is governed by the law of {Governing Law}, and you and we submit to the exclusive jurisdiction of {Jurisdiction}.
Governing law and courts. This Agreement is governed by the laws of {Governing Law}, and you and we submit to the exclusive jurisdiction of the courts 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}
Signature blocks. (For negotiated or enterprise service level agreements accepted by signature rather than clickwrap.)
{Company Name}
Signature: ______________________
Name: ______________________
Title: ______________________
Date: ______________________
Customer
Signature: ______________________
Name: ______________________
Title: ______________________
Date: ______________________
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.
