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.

Document control

Approvals

Revision history

Contents

1. Agreement overview
2. Parties and contacts
3. Service description
4. Definitions
5. Service hours
6. Service levels
7. Measurement and reporting
8. Exclusions
9. Provider responsibilities
10. Customer responsibilities
11. Support channels and incident handling
12. Escalation
13. Service credits
14. Review and change
15. Term and termination
16. Signatures
17. Appendices

1. Agreement overview

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

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

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

3. Service description

[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."]

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

4. Definitions

5. Service hours

6. Service levels

6.1 Availability

Monthly availability is calculated as:

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.

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

6.2 Incident response and resolution

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

7. Measurement and reporting

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

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

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

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

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

11.1 Channels

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

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

12. Escalation

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

13. Service credits

13.1 Availability credits

13.2 Response time credits

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

• 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

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

Signed by the authorised representatives of the parties.

17. Appendices

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:

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

Appendix C. Related documents

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.