# Service Level Agreement: [Service name] between [Provider] and [Customer]

> Complete service level agreement (SLA) between a service provider and a
> customer: parties, service description, definitions, service hours,
> measurable service levels, measurement and reporting, exclusions,
> responsibilities, support and escalation, service credits, review,
> termination and signatures. Based on common IT service management
> practice and the widely used distinction between SLA, SLO and SLI.
> Replace every `[bracketed]` value and every row marked *Example*.
>
> **Format, not legal advice.** This template shows a typical structure
> and wording. Contract terms, liability and remedies depend on your
> jurisdiction and commercial agreement; have the final text reviewed by
> qualified counsel.

<!--
Guidance: How to use this template
- Agree the measurement method (section 7) at the same time as the
  numbers in section 6. A target without an agreed measurement causes
  disputes every month.
- Set external SLA targets looser than internal SLOs, so the team is
  alerted and acts before the contract is breached.
- Keep exclusions specific and short. Broad exclusions undermine trust
  and may be unenforceable.
- If this SLA is a schedule to a master agreement, align defined terms
  and order of precedence with that agreement (section 1.4).
-->

## Document control

<!-- Guidance: Identify the agreement version precisely; customers and finance teams will cite it when claiming credits. -->

| Field | Value |
|---|---|
| Agreement ID | [SLA-CUSTOMER-2026-01] |
| Service | [Service name and plan or tier] |
| Version | [0.1] |
| Status | [Draft / Under negotiation / Signed / Superseded] |
| Effective date | YYYY-MM-DD |
| Term | [12 months, renewing automatically unless terminated per section 15] |
| Provider owner | [@service-owner] |
| Customer owner | [Customer contact name] |
| Parent agreement | [Master services agreement reference and date] |
| Classification | [Confidential] |

### Approvals

| Role | Organisation | Name | Decision | Date |
|---|---|---|---|---|
| Service owner | [Provider] | [@name] | [Approved] | YYYY-MM-DD |
| Commercial / legal | [Provider] | [@name] | [Approved] | YYYY-MM-DD |
| Service manager | [Customer] | [Name] | [Approved] | YYYY-MM-DD |
| Procurement / legal | [Customer] | [Name] | [Approved] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Every change to targets, credits or exclusions is a contract change; record who agreed it. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft for negotiation |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Customer requested P1 response of 15 min; agreed for Enterprise tier only |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Signed by both parties |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Agreement overview](#1-agreement-overview)
2. [Parties and contacts](#2-parties-and-contacts)
3. [Service description](#3-service-description)
4. [Definitions](#4-definitions)
5. [Service hours](#5-service-hours)
6. [Service levels](#6-service-levels)
7. [Measurement and reporting](#7-measurement-and-reporting)
8. [Exclusions](#8-exclusions)
9. [Provider responsibilities](#9-provider-responsibilities)
10. [Customer responsibilities](#10-customer-responsibilities)
11. [Support channels and incident handling](#11-support-channels-and-incident-handling)
12. [Escalation](#12-escalation)
13. [Service credits](#13-service-credits)
14. [Review and change](#14-review-and-change)
15. [Term and termination](#15-term-and-termination)
16. [Signatures](#16-signatures)
17. [Appendices](#17-appendices)

## 1. Agreement overview

<!-- Guidance: State in a paragraph what the agreement covers and how it relates to other contracts. -->

### 1.1 Purpose

This agreement sets out the levels of service that [Provider] will
deliver to [Customer] for [Service], how those levels are measured and
reported, and the remedies available if they are not met.

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Production environment of [Service], [plan/tier] | Non-production and trial environments |
| *Example:* Public API and web application | Customer-built integrations and custom code |
| *Example:* Support for the named services in section 3 | Third-party services the Customer contracts directly |
| [Item] | [Item] |

### 1.3 Objectives

- Provide a shared, measurable definition of acceptable service.
- Set clear responsibilities for both parties.
- Provide a predictable process for reporting, escalation and credits.

### 1.4 Relationship to other agreements

[State the order of precedence. Example: "This SLA is Schedule 2 to the
Master Services Agreement dated YYYY-MM-DD. If this SLA conflicts with
the Master Services Agreement, the Master Services Agreement prevails
except for service levels and service credits."]

## 2. Parties and contacts

<!-- Guidance: Name legal entities exactly as in the contract, plus operational contacts who will actually use the SLA. -->

| Party | Legal name | Registered address | Company number |
|---|---|---|---|
| Provider | [Legal entity name] | [Address] | [Number] |
| Customer | [Legal entity name] | [Address] | [Number] |

| Role | Provider contact | Customer contact |
|---|---|---|
| Service / account manager | [Name, email, phone] | [Name, email, phone] |
| Technical contact | [Name, email] | [Name, email] |
| Escalation contact | [Name, email, phone] | [Name, email, phone] |
| Billing contact | [Name, email] | [Name, email] |

Each party notifies the other in writing within [10 working days] of a
change of contact.

## 3. Service description

<!-- Guidance: Describe what the customer receives in plain terms. Reference the service catalogue entry if there is one. -->

[Describe the service. Example: "[Service] is a hosted order management
platform providing a web application and REST API for creating,
tracking and fulfilling orders, including data storage, backups and
standard integrations listed below."]

| Component | Description | Covered by availability target |
|---|---|---|
| *Example:* Web application | Browser-based user interface at [URL] | Yes |
| *Example:* Public API | REST API at [URL], version [v2] | Yes |
| *Example:* Webhooks | Event notifications to customer endpoints | No, best effort; delivery latency target in 6.3 |
| *Example:* Reporting exports | Scheduled CSV exports | No |
| [Component] | [Description] | [Yes / No] |

Data location: [region or country]. Backups: [frequency and retention,
for example "daily, retained 35 days, stored in a second region"].

## 4. Definitions

<!-- Guidance: Define every term used in targets and credits. Write your own definitions; keep them consistent with the parent agreement. -->

| Term | Meaning in this agreement |
|---|---|
| Service level indicator (SLI) | A quantitative measure of one aspect of the service, such as the share of successful requests or response time. |
| Service level objective (SLO) | An internal target value for an SLI that the Provider aims to meet. SLOs are usually stricter than the SLA and are not contractual. |
| Service level agreement (SLA) | This agreement: the commitments the Provider makes to the Customer, with the remedies that apply if they are not met. |
| Availability | The percentage of minutes in a measurement period in which the service is available, calculated as in 6.1. |
| Downtime | A minute in which [more than 5% of valid requests fail with a server error] or the service cannot be reached from the Provider's external monitoring locations. |
| Scheduled maintenance | Work announced at least [5 working days] in advance and performed within the maintenance window in section 5. |
| Incident | An unplanned interruption or reduction in quality of the service. |
| Priority | The urgency and impact classification of an incident (section 6.2). |
| Response time | Time from the Customer's report (or the Provider's detection) to the first meaningful human response. |
| Resolution time | Time until the service is restored or a workaround is in place that removes the business impact. |
| Measurement period | One calendar month, in UTC. |
| Service credit | A reduction of fees credited to the Customer when a service level is missed (section 13). |
| Working day / hours | [Monday to Friday, 09:00 to 18:00, time zone], excluding public holidays in [country]. |

## 5. Service hours

<!-- Guidance: Distinguish when the service is available from when support staff are working. Customers often confuse the two. -->

| Item | Hours |
|---|---|
| Service availability hours | 24 hours a day, 7 days a week |
| Standard support hours | [Monday to Friday, 08:00 to 20:00, time zone] |
| Priority 1 support | 24x7 for [Enterprise tier] |
| Scheduled maintenance window | [Sunday 01:00 to 05:00 UTC], at most [4 hours] per month |
| Emergency maintenance | Any time, with as much notice as practical; counted as downtime unless excluded in section 8 |

## 6. Service levels

<!-- Guidance: Every target must be measurable from data both parties can see or audit. Avoid "best effort" for anything with a credit attached. -->

### 6.1 Availability

Monthly availability is calculated as:

$$
A = \frac{T_{\text{total}} - T_{\text{excluded}} - T_{\text{down}}}{T_{\text{total}} - T_{\text{excluded}}} \times 100\%
$$

where $T_{\text{total}}$ is the number of minutes in the month,
$T_{\text{excluded}}$ the minutes excluded under section 8 (including
scheduled maintenance), and $T_{\text{down}}$ the downtime minutes.

| Tier | Availability target | Allowed downtime per 30-day month |
|---|---|---|
| *Example:* Standard | 99.5% | 3 h 36 min |
| *Example:* Business | 99.9% | 43 min 12 s |
| *Example:* Enterprise | 99.95% | 21 min 36 s |
| [Tier] | [%] | [Time] |

Allowed downtime per month is $(1 - A) \times 43{,}200$ minutes for a
30-day month.

### 6.2 Incident response and resolution

| Priority | Definition | Example | Response time | Resolution target | Update frequency |
|---|---|---|---|---|---|
| P1 Critical | Service unavailable or major function unusable for all or most users; no workaround | Users cannot log in | 30 min, 24x7 | 4 h | Every 60 min |
| P2 High | Major function degraded or unavailable for a subset of users; workaround difficult | API error rate above 5% for one region | 2 h (support hours) | 1 working day | Every 4 h |
| P3 Medium | Minor function impaired; reasonable workaround exists | One report export fails | 1 working day | 5 working days | Daily |
| P4 Low | Question, cosmetic issue or feature request | Label misaligned | 2 working days | Next planned release or declined | On change |

The Provider assigns the initial priority based on the Customer's
description and may adjust it with an explanation. Resolution targets
are objectives; only response time and availability carry service
credits unless stated otherwise in section 13.

### 6.3 Performance and other service levels

| ID | Service level | Target | Measurement |
|---|---|---|---|
| SL-01 | *Example:* API latency | 95% of API requests complete in under 800 ms | Provider server-side metrics, monthly |
| SL-02 | *Example:* Webhook delivery | 99% delivered within 60 s of the event | Delivery logs |
| SL-03 | *Example:* Data restore on request | Restore from backup within 1 working day | Ticket timestamps |
| SL-04 | *Example:* Recovery objectives in a disaster | RTO 8 h, RPO 1 h | Annual DR test report |
| [SL-nn] | [Service level] | [Target] | [Measurement] |

## 7. Measurement and reporting

<!-- Guidance: Name the data source, the measurement point and the report. If customers can see a status page, say how it relates to the official figure. -->

### 7.1 Measurement method

- Availability is measured by the Provider's external synthetic monitoring from [three] locations every [60 seconds], combined with server-side error rates.
- A minute counts as downtime when [two or more locations fail, or server-side error ratio exceeds 5%].
- Response and resolution times are measured from timestamps in the Provider's support system.
- All times are recorded in UTC.

### 7.2 Reporting

| Report | Content | Frequency | Delivered by | Channel |
|---|---|---|---|---|
| Service level report | Availability, incidents by priority, response times, credits due | Monthly, by working day [5] | Provider service manager | Email and customer portal |
| Incident report | Timeline, impact, cause, corrective actions | Within [5 working days] of each P1 | Provider | Email |
| Service review | Trends, improvement plan, upcoming changes | Quarterly | Both parties | Meeting |
| Status page | Real-time status and incident updates | Continuous | Provider | [Status page URL] |

### 7.3 Disputes about measurements

The Customer may dispute a report within [30 days] of receipt, with
supporting evidence. The parties review the data together; unresolved
disputes follow the dispute process in the parent agreement.

## 8. Exclusions

<!-- Guidance: Keep the list short and specific. Each exclusion should be something genuinely outside the Provider's control or caused by the Customer. -->

Downtime or missed service levels are not counted when caused by:

1. Scheduled maintenance performed within the window and notice period in section 5.
2. Actions or omissions of the Customer or its users, including misuse, exceeding documented usage limits, or changes made against Provider guidance.
3. Customer equipment, networks, integrations or third-party services not provided by the Provider.
4. Suspension of the service in accordance with the parent agreement, for example for non-payment or security risk.
5. Force majeure events as defined in the parent agreement.
6. Features labelled beta, preview or trial.
7. [Other specific exclusion]

## 9. Provider responsibilities

<!-- Guidance: List what the Provider commits to do beyond the numeric targets. -->

The Provider will:

- operate, monitor and maintain the service to meet the levels in section 6;
- give notice of scheduled maintenance at least [5 working days] in advance;
- notify the Customer of P1 incidents within [30 minutes] of detection;
- provide the reports in section 7.2;
- maintain backups and disaster recovery arrangements as described in section 3 and SL-04;
- maintain security controls as described in [security schedule or policy];
- notify the Customer of material changes to the service in line with section 14.

## 10. Customer responsibilities

<!-- Guidance: Service levels often depend on the customer. State what they must do for the targets to apply. -->

The Customer will:

- report incidents through the channels in section 11 with the information requested in 11.2;
- name authorised contacts and keep them current;
- use the service in line with the documentation and usage limits;
- provide reasonable access, information and cooperation needed to resolve incidents;
- keep its own credentials secure and manage its users' access;
- test and maintain its own integrations, including updating to supported API versions within [12 months] of a deprecation notice.

## 11. Support channels and incident handling

<!-- Guidance: Tell the customer exactly how to get help, and what information speeds it up. -->

### 11.1 Channels

| Channel | Use for | Availability | Contact |
|---|---|---|---|
| Phone hotline | P1 incidents | 24x7 for eligible tiers | [Number] |
| Support portal | All priorities | 24x7 submission; handled in support hours | [URL] |
| Email | P3 and P4 | Support hours | [Address] |
| Status page | Service status and updates | 24x7 | [URL] |

### 11.2 Information to include in a report

Affected component, time the issue started (with time zone), number of
users affected, error messages or request IDs, steps to reproduce, and
business impact.

### 11.3 Incident lifecycle

```mermaid
stateDiagram-v2
  [*] --> Reported
  Reported --> Acknowledged: response time met
  Acknowledged --> InProgress
  InProgress --> WorkaroundProvided
  InProgress --> Resolved
  WorkaroundProvided --> Resolved
  Resolved --> Closed: customer confirms or 5 working days pass
  Closed --> [*]
```

The lifecycle above shows the states recorded in the support system;
response and resolution times are measured between these states.

## 12. Escalation

<!-- Guidance: Give named levels with contacts and time triggers. Escalation is a right of both parties, not a complaint. -->

| Level | Provider contact | Customer contact | Trigger |
|---|---|---|---|
| 1 | Support engineer on duty | Reporting user | Initial report |
| 2 | Support team lead [name, contact] | Customer IT manager [name] | Response target missed, or no progress on P1 for 2 h |
| 3 | Head of service delivery [name, contact] | Customer head of IT [name] | P1 unresolved after 4 h, or repeated misses in a month |
| 4 | Executive sponsor [name, contact] | Customer executive sponsor [name] | Material breach or relationship risk |

Either party may escalate one level at a time by contacting the named
person and stating the ticket number and reason.

## 13. Service credits

<!-- Guidance: Credits should be meaningful but proportionate. State the claim process, cap and whether credits are the sole remedy (agree this with counsel). -->

### 13.1 Availability credits

| Monthly availability achieved | Credit as % of monthly fee for the affected service |
|---|---|
| *Example:* Below 99.9% and at or above 99.5% | 5% |
| *Example:* Below 99.5% and at or above 99.0% | 10% |
| *Example:* Below 99.0% and at or above 95.0% | 25% |
| *Example:* Below 95.0% | 50% |
| [Range] | [%] |

### 13.2 Response time credits

| Missed target | Credit |
|---|---|
| *Example:* P1 response time missed | 2% of monthly fee per occurrence |
| *Example:* P2 response time missed three or more times in a month | 2% of monthly fee |
| [Target] | [Credit] |

### 13.3 Conditions

- Total credits in a month are capped at [50%] of the monthly fee for the affected service.
- The Customer requests credits in writing within [30 days] after the monthly report.
- Credits are applied to the next invoice and are not paid as cash unless the agreement ends.
- [State whether service credits are the Customer's sole and exclusive remedy for missed service levels, as agreed with counsel.]
- Repeated failure: if availability is below [99.0%] in [three] consecutive months, the Customer may terminate the affected service under section 15.

## 14. Review and change

<!-- Guidance: Describe how both parties review performance and how the SLA itself can be changed. -->

- The parties hold a service review every [quarter] using the reports in 7.2.
- This SLA is reviewed at least [annually] and at renewal.
- Either party may propose changes in writing. Changes take effect only when signed by both parties and recorded in the revision history.
- The Provider may improve service levels at any time; it may not reduce them during the term without the Customer's written agreement.

## 15. Term and termination

<!-- Guidance: Align with the parent agreement. Add only SLA-specific rights here. -->

This SLA starts on the effective date and continues for the term in
the document control table. It renews and ends together with the parent
agreement. In addition to rights in the parent agreement, the Customer
may terminate the affected service with [30 days] written notice under
the repeated-failure condition in 13.3. On termination the Provider
supports data export as described in [data return clause].

## 16. Signatures

<!-- Guidance: Use authorised signatories as defined by each organisation. Electronic signatures are typically acceptable; confirm with counsel. -->

Signed by the authorised representatives of the parties.

| | Provider | Customer |
|---|---|---|
| Organisation | [Legal entity name] | [Legal entity name] |
| Name | [Name] | [Name] |
| Title | [Title] | [Title] |
| Signature | ____________________ | ____________________ |
| Date | YYYY-MM-DD | YYYY-MM-DD |

## 17. Appendices

<!-- Guidance: Add tier tables, monitoring locations, and examples of credit calculations. -->

### Appendix A. Worked credit example

*Example:* In a 30-day month (43,200 minutes) with 180 minutes of
scheduled maintenance and 62 minutes of downtime on the Business tier:

$$
A = \frac{43{,}200 - 180 - 62}{43{,}200 - 180} \times 100\% \approx 99.856\%
$$

This is below 99.9% and at or above 99.5%, so the credit is 5% of the
monthly fee.

### Appendix B. Monitoring locations and endpoints

| Location | Endpoint checked | Interval |
|---|---|---|
| [Region 1] | [URL or health endpoint] | 60 s |
| [Region 2] | [URL] | 60 s |
| [Region 3] | [URL] | 60 s |

### Appendix C. Related documents

| Document | Reference |
|---|---|
| Master services agreement | [Reference] |
| Data processing agreement | [Reference] |
| Security schedule | [Reference] |
| Service catalogue entry | [Reference] |

## Standard and licence note

Based on common IT service management practice for service level
agreements and on the widely used SRE distinction between SLIs, SLOs and
SLAs. The definitions and wording are original text written for this
collection. This template is a document format, not legal advice; have
any agreement reviewed by qualified counsel before signing. Template
licence: MIT.