Sample Service Level Agreement

Before you use this SLA template

This is but a sample, for an SLA written for one of our API SaaS services.

  1. Adjust it to match your business and systems

  2. Let your IT department review it

  3. Let your legal department review it

Date

Version

Changes

Date

Version

Changes

2022-01-25

v1.0.1

Changed order, Indicators, Objectives and Agreement.

2022-01-24

v1.0.0

 

Service Level Agreement

An SLA (service level agreement) is an agreement between provider and client about measurable metrics like uptime, responsiveness and responsibilities.

1 Definitions

1.1 This document is referred to as the “Agreement”.

1.2 “Service” is the <Vaccinated API>.

1.3 “Subscription” is an ongoing payment for the Service.

1.3 “Client” is a legal entity paying for a Subscription.

1.4 “Vendor” is <inCAPS AB, 559319-0787>.

2 Service Description

Service Scope

System

Criticality

Description

System

Criticality

Description

Vaccinated API

Highest

Essential for service function of validating DCC.

Vaccinated Repository

High

Service can continue during a short interruption in this system, but a failure should be fixed momentarily.

Certificate Update Service

Low

Certificates do not update often. The Service will continue functioning without this Service, but it should be fixed.

Out of Scope

System

Criticality

Description

System

Criticality

Description

API Client

Highest

Client is responsible for development, maintenance and connectivity of the API Client.

Digital Covid Certificate Trust Point

Low

Updates to Digital Covid Certificates. Hosted by third party provider.

3 Service Level Indicators

An SLI (service level indicator) is a defined quantitative measure of the level of service that is provided.

3.1 Availability is measured through health checks to the Vaccinated API once per minute. The aggregate is done over 1 month.

3.2 Updates of certificates to the Vaccinated Repository is done once per day over a 48 hour time window. Failure is when Vaccinated Repository fails to get updates from trust point. Failure rate is aggregated over a 1 month period.

3.3 Request latency is measured on the Validate endpoint of Validation API at the server side. It an aggregation of the 99th percentile over a period of 15 minutes, and only when number of requests exceeds 10.

3.4 Error rates are measured on the Validate endpoint of Validation API and only for HTTP 500 status or service unavailable. It is aggregated in a 24 hour time period. Errors during planned and unplanned downtime are exempted from this metric.

3.5 Throughput is measured in successful requests per minute to the Validate endpoint of the Validation API. It is aggregated in a 15 minute time period.

4 Service Level Objectives

An SLO (service level objective) is a target value or range of values for a specific service level that is measured by an SLI.

4.1 Vaccinated API guarantees an availability of 99% during business hours. This equals 7 hours, 18 minutes and 17 seconds of error budget, to be used for planned and unplanned service disruptions. (SLI 3.1)

4.2 Updates of certificates to the Vaccinated Repository is guaranteed a 90% success rate. (SLI 3.2)

4.3 Request latency for Validate request will always be within 500 ms. (SLI 3.3)

4.4 Error rates to the Validate endpoint will always be within 90% success rate. (SLI 3.4)

4.5 Vaccinated API guarantees a throughput of 120 requests/min. Requests that exceeds this throughput may be declined to avoid denial of service. (SLI 3.5)

5 Client Responsibilities

5.1 The Client is responsible for maintaining a registered e-mail address with the Vendor, with which the Vendor can reach the Client for communication.

5.2 The Client is responsible for building and maintaining the API client that communicates with the Service.

5.3 The Client is responsible for not overloading the Vaccinated API with requests beyond agreed service level objectives.

5.4 The Client is responsible for updating the API Client to new versions of the Service before current version becomes deprecated.

5.5 The Client is responsible for not misusing the Service in a way that is not documented or intended.

5.6 The Client is responsible for the security and integrity of the license key provided by the Vendor for accessing the Service.

5.7 The Client is responsible for reporting and replacing a license key that has been compromised.

6 Vendor Responsibilities

6.1 The Vendor is responsible for managing the Service within the agreed SLOs.

6.2 The Vendor is responsible for notifying the Client of unplanned service disruptions, at least 24 hours after the service has been resumed.

6.3 The Vendor is responsible for notifying the Client of planned service disruptions at least 5 days ahead of time.

6.4 The Vendor is responsible for maintaining and develop the Service.

6.5 The Vendor is responsible for releasing new versions of the Service that are backwards compatible with existing API Clients.

6.6 The Vendor is responsible for notifying the Client about deprecations of the Service, 6 months in advance of removal.

6.7 The Vendor is responsible for collecting, aggregating and publishing monthly reports on SLIs, where the Client can easily find them.

7 Responsibility Exemptions

7.1 The Vendor is not responsible for Systems noted as “Out of Scope” in the service description.

7.2 The Vendor does not take responsibility for service disruptions caused by its service provider Microsoft Azure.

7.3 The Vendor does not take responsibility for service disruptions caused by force majeure, there by included war, earthquakes, tornadoes, epidemics and pandemics.

8 Service Level Agreement

8.1 With this Agreement the Vendor agrees to meet the SLO’s and Vendor Responsibilities of the Service.

8.2 This Agreement doesn’t require a separate signature, but is accepted as attachment of the purchase agreement.

8.3 This Agreement is valid as long as the Client has an active Subscription.

8.4 The Vendor is responsible for maintaining the agreement and will distribute changes to this Agreement to Client’s registered e-mail 2 months in advance.

8.5 The Client can choose to end their Subscription, without notice period, when disagreeing to changes to this Agreement.

9 Support

9.1 Reporting of incidents, problems and service requests should be done to support e-mail support@incaps.se

9.2 Service hours are 8am to 12am, Central European Timezone. All workdays except public holidays. Issues raised outside these hours will be dealt with at the start of normal service hours.

9.3 The Vendor will triage your service request within the following times

Request Type

First Response

Time to Resolution

Request Type

First Response

Time to Resolution

Incident

8 service hours

See resolution table below.

Problem

24 service hours

-

Support

40 service hours

-

Change Request

-

-

9.4 Incidents will be triaged with Urgency and Impact levels. Urgency is a measure of time for an incident to significantly impact your business.

Urgency

Definition

Urgency

Definition

Highest

The incident is at this moment causing significant loss of income, and severely impacting the business.

High

The incident is causing loss of income that is expecting to increase unless the service is restored.

Medium

The incident impacts the business with loss of income until the service is restored.

Low

The incident will impact the business with loss of income unless the service is restored.

Lowest

The incident might impact the business with loss of income unless the service is restored.

Impact measures the effect of an incident on business processes.

Impact

Definition

Impact

Definition

Expensive / Widespread

The incident is a complete black-out of the Service, or a major part of the service.

Significant / Large

The Service is mostly working, but with reduced performance and reliability.

Moderate / Limited

An important part of the Service is not working, or working unreliably.

Minor / Localised

A minor part of the Service is not working or performing as it should.

9.5 Once Urgency and Impact are established, the priority of the issue will be set according to the following matrix, and service restore time will be set.

URGENCY →

Highest

High

Medium

Low

Lowest

URGENCY →

Highest

High

Medium

Low

Lowest

IMPACT ↓

 

 

 

 

 

Extensive / Widespread

Higest priority

High priority

Medium priority

Low priority

Lowest priority

Significant / Large

Highest priority

High priority

Medium priority

Low priority

Lowest priority

Moderate / Limited

Medium priority

Medium priority

Low priority

Lowest priority

Lowest priority

Minor / Localized

Low priority

Low priority

Lowest priority

Lowest priority

Lowest priority

Priority

Time to Resolution

Priority

Time to Resolution

Highest

8 service hours

High

24 service hours

Medium

40 service hours

Low

- (no action)

Lowest

- (no action)

Time to Resolution is effective time. The clock will stop while waiting for response for the Client to provide more information.

Low and Lowest priority incidents will be closed without action, but added to the product backlog.

10 Reparations

10.1 There will be no reparations unless the Client has fulfilled the Client Responsibilities.

10.2 The Client will be allowed to cancel a Subscription immediately when Vendor is not fulfilling their Vendor Responsibilities, without paying additional Subscription fees for notice period.

10.3 The Client will be repaid for Subscription fees for periods when this Agreement was not fulfilled by the Vendor. If the Client choose to stay as a Customer, credit will be added to their Subscription. If the Client choose to cancel the Subscription, money will be repaid.