Free Word download β’ Edit online β’ Save & share with Drive β’ Export to PDF
A Service Level Agreement (SLA) is a legally binding contract β or a formal addendum to an existing services contract β between a service provider and a customer that converts informal performance expectations into measurable, enforceable obligations. It defines quantitative service standards (uptime percentage, incident response time, resolution time), the methodology used to measure them, the credits owed to the customer when standards are missed, and the circumstances that excuse the provider from those commitments. Unlike a general service agreement that describes what will be delivered, an SLA specifies how well it must be delivered and what happens when it falls short.
Without a signed SLA, every performance dispute becomes a credibility contest rather than a contract interpretation exercise β and providers almost always argue that informal uptime benchmarks were aspirational, not contractual. The consequences are concrete: enterprise customers stall procurement approval without an SLA in hand; regulated industries in financial services and healthcare require documented third-party service standards as a compliance prerequisite under DORA, OSFI, and HIPAA frameworks; and without a defined credit schedule, a prolonged outage leaves a customer with no contractual remedy short of costly litigation. This template gives providers and customers a structured starting point β measurable targets, a tiered credit schedule, a clear exclusions list, and a termination right for chronic failures β so that performance expectations are documented before the first incident, not debated after it.
| If your situation is⦠| Use this template |
|---|---|
| Providing managed IT or infrastructure services | IT Service Level Agreement |
| SaaS product with an enterprise uptime guarantee | SaaS Service Level Agreement |
| Cloud hosting or infrastructure-as-a-service | Cloud Hosting SLA |
| Outsourced customer support or help desk | Help Desk SLA |
| Professional services retainer with staffing commitments | Professional Services SLA |
| Internal IT department serving business units | Internal (OLA) Operational Level Agreement |
| Telecom or network connectivity provider | Network Services SLA |
Why it matters: Committing to 99.99% availability on infrastructure that historically delivers 99.9% creates automatic credit liability every month and signals to customers that the SLA is not credible.
Fix: Run 6β12 months of historical uptime data through the credit schedule before finalizing targets, and build in at least a 0.1% buffer below your actual average performance.
Why it matters: Without a floor, every transient 30-second error during peak traffic becomes a downtime event, making the uptime calculation commercially unusable and the credit schedule permanently triggered.
Fix: Define downtime as complete inaccessibility lasting more than a specified consecutive period β 5 minutes is a common standard for web-based services.
Why it matters: Courts in the UK, EU, and several US states have refused to enforce sole-remedy clauses where a provider's willful or grossly negligent conduct caused an extended outage, exposing the provider to unlimited damages instead.
Fix: State that credits are the exclusive remedy for SLA failures caused by ordinary operational issues, but expressly preserve the customer's right to claim actual damages for gross negligence or wilful misconduct.
Why it matters: An exclusion for 'third-party infrastructure failures' that implicitly covers the provider's AWS or Azure tenancy can render the uptime commitment illusory β courts and arbitrators have voided such clauses.
Fix: Limit third-party exclusions to infrastructure genuinely outside the provider's control (e.g., a BGP routing failure at the customer's ISP), and explicitly state that the provider's chosen hosting infrastructure is not excluded.
Why it matters: Staff turnover means a named escalation contact can become unreachable, and the customer has no contractually specified fallback β leaving escalation procedures unenforceable in practice.
Fix: Use job titles and generic contact details (e.g., noc@provider.com, support-escalations@provider.com) rather than individual names, and update contact schedules outside the main agreement.
Why it matters: A customer locked into a multi-year contract with credits as the only remedy has no commercial exit if the provider misses targets every month β credits simply subsidize consistently poor service.
Fix: Include a termination-for-cause provision that activates when credits exceed a defined percentage of monthly fees (e.g., 30%) in any three consecutive months, allowing the customer to exit without an early-termination penalty.
In plain language: Identifies the provider and customer as legal entities, describes the specific services covered, and states when the SLA takes effect and how long it runs.
This Service Level Agreement is entered into as of [EFFECTIVE DATE] between [PROVIDER LEGAL NAME] ('Provider') and [CUSTOMER LEGAL NAME] ('Customer'). This Agreement governs Provider's delivery of [SERVICE DESCRIPTION] ('Services') as defined in the Master Services Agreement dated [MSA DATE].
Common mistake: Scoping the SLA to cover all services the provider offers rather than the specific services purchased. When new services are added, the SLA's metrics become inapplicable to them, creating enforcement disputes.
In plain language: States the uptime percentage commitment β e.g., 99.9% monthly β and defines exactly how availability is calculated, including what counts as downtime.
Provider will maintain Service Availability of no less than [99.9]% during each calendar month, calculated as: (Total Minutes in Month β Downtime Minutes) Γ· Total Minutes in Month Γ 100. 'Downtime' means the Service is inaccessible to all users for more than [5] consecutive minutes, excluding Scheduled Maintenance and Exclusions.
Common mistake: Not defining the minimum outage duration that counts as downtime. Without a floor (e.g., 5 consecutive minutes), every transient error becomes a credit-triggering event, making the SLA commercially unworkable.
In plain language: Sets the maximum time the provider has to acknowledge and resolve incidents, tiered by severity level.
P1 (Service Unavailable): Response within [15] minutes, Resolution within [4] hours. P2 (Significant Degradation): Response within [1] hour, Resolution within [8] Business Hours. P3 (Minor Issue): Response within [4] Business Hours, Resolution within [3] Business Days. P4 (General Inquiry): Response within [1] Business Day, Resolution within [5] Business Days.
Common mistake: Expressing resolution times in calendar hours without defining business hours. A P2 incident opened at 5 PM Friday with an 8-hour resolution SLA resolves Monday morning under a business-hours definition β that gap must be explicit.
In plain language: Explains the tools, data sources, and calculation method used to measure performance, and commits the provider to delivering a regular service report.
Provider will measure Service Availability using [MONITORING TOOL / THIRD-PARTY URL]. Provider will deliver a monthly SLA report to [CUSTOMER CONTACT] by the [5th] business day of the following month, showing actual uptime, incident count by priority, and credits earned, if any.
Common mistake: Allowing the provider to self-report availability without specifying the monitoring tool or methodology. When a credit dispute arises, neither party has an agreed source of truth.
In plain language: Defines the credit the customer receives when the provider misses an availability or response target, expressed as a percentage of monthly fees.
If monthly Service Availability falls below [99.9]% but equals or exceeds [99.0]%, Customer receives a credit equal to [10]% of the monthly fee for that Service. Below [99.0]% but at or above [95.0]%: [25]% credit. Below [95.0]%: [50]% credit. Credits are applied to the next invoice and do not exceed the monthly fee for the affected Service.
Common mistake: Making service credits the customer's only remedy for any and all service failures. Courts in several jurisdictions have found that a sole-remedy clause barring damages for prolonged, willful outages is unconscionable β add a carve-out for gross negligence or wilful misconduct.
In plain language: Lists the circumstances β scheduled maintenance, customer-caused issues, third-party failures, force majeure β that are excluded from downtime calculations and do not trigger credits.
The following are excluded from Downtime calculations: (a) Scheduled Maintenance announced at least [72] hours in advance; (b) outages caused by Customer's acts or omissions; (c) failures of third-party networks or infrastructure outside Provider's control; (d) Force Majeure Events; (e) Customer's failure to implement Provider-recommended patches within [30] days of notice.
Common mistake: Writing exclusions so broadly that they swallow the uptime commitment. Excluding 'any third-party dependency' can cover the provider's own cloud infrastructure β courts have refused to enforce SLA exclusions that make the uptime guarantee illusory.
In plain language: Defines the step-by-step escalation path if an incident is not resolved within the committed window, including contact names, titles, and timeframes.
If a P1 incident is not resolved within [2] hours, Provider will escalate to [ESCALATION CONTACT NAME / TITLE] and notify Customer's [CUSTOMER ESCALATION CONTACT] by phone. If unresolved after [4] hours, Provider's [C-LEVEL TITLE] will be engaged and a bridge call established every [60] minutes until resolution.
Common mistake: Listing escalation contacts by name rather than by role. Personnel change β an SLA that escalates to 'Jane Smith' becomes unenforceable the moment Jane leaves.
In plain language: States the process and deadline by which the customer must submit a credit claim, and the timeframe in which the provider must respond.
To receive a Service Credit, Customer must submit a written credit request to [PROVIDER SUPPORT EMAIL] within [30] days of the end of the measurement month in which the missed target occurred. Provider will respond within [10] business days with a credit confirmation or written dispute. Failure to submit within [30] days waives the credit for that period.
Common mistake: No credit-claim deadline at all. Without one, customers can accumulate months of potential credits and submit them simultaneously, creating a large, disputed liability for the provider.
In plain language: Requires the parties to review targets annually, sets the process for amending metric levels, and states the customer's right to terminate the underlying agreement if credits reach a defined threshold.
The parties will review SLA targets no less than annually. Amendments require written consent of both parties. If Service Credits exceed [30]% of monthly fees in any [3] consecutive months, Customer may terminate the underlying Master Services Agreement on [30] days' written notice without early-termination penalty.
Common mistake: No termination right for persistent SLA failures. A customer locked into a 3-year contract with only credit remedies has no commercial leverage if the provider delivers chronically poor service β and courts in the UK and EU have found this one-sided.
In plain language: Specifies which jurisdiction's law governs the SLA and how disputes β including credit disputes β are resolved.
This Agreement is governed by the laws of [STATE / PROVINCE / COUNTRY], without regard to conflict-of-law principles. Any dispute arising under this Agreement that is not resolved within [30] days of written notice shall be submitted to binding arbitration administered by [AAA / JAMS / LCIA] in [CITY], except that either party may seek injunctive relief in any court of competent jurisdiction.
Common mistake: Choosing a governing law inconsistent with the data-processing addendum or master agreement. Mismatched governing law across linked documents creates jurisdictional ambiguity that lengthens and complicates any dispute.
Enter the full legal entity names and registration details for both provider and customer. If this SLA is an addendum to a Master Services Agreement, reference its title and execution date explicitly so the documents are legally linked.
π‘ Confirm the provider entity name matches the contracting entity on the MSA β a subsidiary name mismatch is a common source of enforceability disputes.
List only the services covered by this SLA β not the provider's entire product catalog. Reference the relevant service description, order form, or statement of work by title and date.
π‘ Attach a Schedule A listing each covered service with its service ID or SKU so there is no ambiguity when new services are added later.
Choose the availability percentage (99.9% is standard for most B2B SaaS; 99.99% for mission-critical infrastructure) and define exactly what qualifies as downtime, including the minimum outage duration threshold.
π‘ 99.9% monthly allows about 43 minutes of unplanned downtime per month; 99.99% allows about 4 minutes. Set the target at the level your infrastructure can actually sustain β overpromising creates credit exposure.
Create 3β5 priority levels from critical (service fully unavailable) to low (cosmetic or informational issues). Assign specific response and resolution time commitments to each tier, and define whether those times are in business hours or calendar hours.
π‘ P1 and P2 commitments should always be in calendar hours β critical outages do not stop at 5 PM β while P3 and P4 can run in business hours.
Name the monitoring tool or third-party service used to measure availability. Set the reporting cadence (monthly is standard) and name the delivery date and recipient. Include a sample report format in a schedule if possible.
π‘ Using an independent third-party monitor (e.g., Pingdom, Datadog, StatusPage) rather than the provider's own infrastructure logs builds customer trust and reduces credit disputes.
Create a tiered credit table tied to availability bands (e.g., 99.0β99.9%, 95.0β99.0%, below 95%). Express credits as a percentage of the monthly fee for the affected service, and cap total credits at 100% of that month's fee.
π‘ Add a carve-out stating that credits do not apply where the outage resulted from the provider's gross negligence or wilful misconduct β those situations should trigger the general liability clause instead.
List each exclusion category with enough specificity that it cannot be stretched to cover normal operational failures. For scheduled maintenance, require a minimum advance-notice period (48β72 hours) and a maximum monthly maintenance window (e.g., 4 hours).
π‘ Cap total scheduled-maintenance downtime per month β an unlimited maintenance window can reduce a 99.9% uptime commitment to zero in practice.
Specify the email address for credit submissions, the claim deadline (30 days after the measurement period is standard), the provider's response window, and the annual review date for updating targets.
π‘ Include a dispute resolution step before arbitration β a 15-day good-faith negotiation period resolves most credit disputes without formal proceedings.
A service level agreement (SLA) is a contract β or a formal addendum to a services contract β between a service provider and a customer that defines quantitative performance standards: uptime percentages, response times, resolution times, and the consequences (typically service credits) when those standards are missed. It converts informal performance expectations into measurable, enforceable obligations backed by a credit or termination remedy.
A complete SLA should cover: the parties and services in scope, an uptime or availability target with a clear downtime definition, incident severity tiers with response and resolution times, a measurement methodology naming the monitoring tool and reporting cadence, a credit schedule tied to specific availability bands, a list of exclusions, an escalation path, a credit-claim procedure with a submission deadline, and an annual review cycle. Missing any of these creates ambiguity that surfaces when the first outage occurs.
99.9% monthly availability (sometimes called 'three nines') is the most common standard for B2B SaaS and managed services β it allows approximately 43 minutes of unplanned downtime per month. Mission-critical infrastructure and financial or healthcare platforms often commit to 99.99% ('four nines'), which allows about 4.4 minutes per month. Committing to a higher target than your infrastructure can sustain creates automatic monthly credit liability.
Most SLAs make service credits the exclusive remedy for standard performance failures β this limits the provider's financial exposure to a defined percentage of monthly fees. However, courts in the UK, EU, and several US states have declined to enforce sole-remedy clauses where the provider's conduct was grossly negligent or willful. A well-drafted SLA preserves service credits as the remedy for ordinary failures and expressly reserves the customer's right to claim actual damages for more serious conduct.
A master services agreement (MSA) governs the overall commercial relationship β payment terms, liability caps, IP ownership, confidentiality, and termination rights. An SLA is a specific addendum that defines measurable performance standards and the remedies for missing them. The MSA creates the contract; the SLA specifies the operational standards within it. SLAs typically cross-reference and are governed by the MSA.
Standard exclusions include scheduled maintenance announced in advance (typically with 48β72 hours' notice), outages caused by the customer's own acts or failures, failures of internet infrastructure genuinely outside the provider's control, and force majeure events. Exclusions should be drafted narrowly β overly broad exclusions that cover the provider's own hosting infrastructure can render the uptime commitment commercially meaningless.
For straightforward managed services or SaaS engagements with standard uptime and credit terms, a high-quality template reviewed by a business advisor is often sufficient. Legal review is strongly recommended when the contract involves regulated industries (healthcare, financial services), cross-border services with GDPR or data-residency requirements, contracts above $250K annually, or where the credit and termination structure is heavily negotiated. A 1β2 hour review typically costs $400β$800.
Credits are almost always expressed as a percentage of the monthly fee for the affected service, tiered by how far actual availability falls below the target. A common structure: 10% credit for availability between 99.0% and 99.9%, 25% for 95.0%β99.0%, and 50% for below 95.0%. Total credits are capped at 100% of the affected monthly fee. Credits are applied to the next invoice rather than paid in cash under most SLAs.
Only if the SLA or master agreement includes a termination-for-cause provision tied to SLA performance. Without one, a customer receiving credits every month is contractually entitled to credits only β not termination. Best practice is to include a clause allowing termination without early-termination penalty if credits exceed a defined threshold (e.g., 30% of monthly fees) in any three consecutive measurement periods.
A master services agreement governs the overall commercial relationship β payment, liability, IP, confidentiality, and termination. An SLA is an operational addendum within that relationship, defining measurable performance standards and credit remedies. You typically need both: the MSA creates the contract; the SLA specifies how well the services must perform.
A service agreement covers what services will be delivered and the commercial terms. An SLA specifies how well those services must perform β uptime, speed, availability β and what happens when they fall short. A service agreement without an SLA has no enforceable performance floor; an SLA without a service agreement has no commercial terms.
An IT support agreement defines the scope of support services, staffing, and billing for helpdesk or infrastructure management. An SLA defines the measurable response and resolution standards those support services must meet. The two documents typically operate together, with the support agreement governing scope and the SLA governing performance.
An NDA protects confidential information exchanged between parties β it has no performance metrics or credit structure. An SLA defines operational performance standards and remedies. They serve entirely different functions but are often signed together at the start of a vendor relationship, with the NDA protecting disclosures made during SLA negotiations.
Uptime commitments are central to enterprise sales β 99.9% or 99.99% targets, measured by independent monitoring tools, are a baseline expectation for deals above $50K ARR.
Severity-tiered response and resolution times covering network, server, and end-user support are the core SLA structure, with separate targets for on-site vs. remote support.
HIPAA-covered systems require SLAs that address data availability alongside uptime, with breach-notification timelines and audit-log access commitments included as performance metrics.
Regulators in the US (OCC), UK (FCA), and EU (DORA) require documented SLAs for critical third-party technology providers, with specific resilience and recovery time objectives.
SLAs are governed by general contract law β UCC Article 1 and common law apply depending on whether services are classified as goods or services. Federal sector SLAs must comply with FAR requirements. California courts scrutinize sole-remedy clauses and have found them unenforceable in cases involving gross negligence. Several states require minimum data-breach notification timeframes that should be reflected in SLA metrics for cloud and data services.
SLAs for provincially regulated industries (financial services, healthcare) must align with sector-specific operational resilience requirements set by OSFI and provincial regulators. Quebec's Law 25 imposes data-availability and incident-response obligations on services handling personal information of Quebec residents. Sole-remedy clauses are generally enforceable unless the failure constitutes intentional or gross fault under Quebec civil law.
The UK's Operational Resilience Policy (PRA / FCA) requires regulated financial firms to document SLAs with critical third-party providers, including specific impact tolerances and recovery time objectives. UKGDPR requires data processors to notify controllers of personal data breaches within 72 hours β this timeline should be reflected in SLA incident-reporting clauses. The Unfair Contract Terms Act 1977 can invalidate sole-remedy clauses that are unreasonable.
The EU Digital Operational Resilience Act (DORA), effective January 2025, mandates that financial entities include specific contractual provisions in SLAs with ICT third-party providers, covering availability targets, incident reporting timelines, and audit rights. GDPR Article 28 requires data processing agreements β often incorporated into or alongside the SLA β specifying processor obligations and breach notification within 72 hours. Member states may impose additional sector-specific resilience requirements.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Managed service providers and SaaS companies issuing standard uptime and response-time SLAs for contracts under $100K annually | Free | 1β2 hours |
| Template + legal review | Enterprise contracts above $100K, cross-border services, or regulated industries where an attorney reviews the credit, exclusions, and sole-remedy structure | $400β$800 | 2β5 days |
| Custom drafted | Mission-critical infrastructure contracts, DORA-regulated financial services, healthcare SaaS with HIPAA obligations, or deals with heavily negotiated liability and termination terms | $2,000β$6,000+ | 1β3 weeks |
This document is one of 3,000+ business & legal templates included in Business in a Box.
Access over 3,000+ business and legal templates for any business task, project or initiative.
Customize your ready-made business document template and save it in the cloud.
Share your files and folders with your team. Create a space of seamless collaboration.
"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."
"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."
"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."
Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.
Start freeΒ Β·Β No credit card required
