§1 Introduction

(1) Purpose of the document

The document regulates and defines service levels for the provision of hosting and data center services by Thomas-Krenn.AG.

The SLA is concluded in connection with the provision of services by Thomas-Krenn.AG. The document defines the service levels of the different services, infrastructure parameters and all provided functions.

(2) Validity

The SLA is only valid in connection with a valid contract for services from Thomas-Krenn.AG. The scope of service results from the respective service descriptions listed in this document or, if applicable, the supplementary service descriptions for individual services. The General Terms and Conditions (GTCs) of Thomas-Krenn apply in addition to this SLA.

(3) Scope

The service levels listed in this document apply only if the customer is not in default of payment for the services. For the duration of any default, the rights and obligations under this SLA will be mutually suspended.

The SLA described in this document does not cover the following cases:

- Force majeure

- Overriding legal or regulatory requirements (including orders of ordinary courts of the respective country in which the operation takes place)

- Overload and/or faulty operation of the services provided by Thomas-Krenn.AG caused by the customer

- Changes to a service or configuration that has been performed or commissioned by the customer

- Maintenance work of the partner

- Blocking of individual services or an entire account due to improper use

(4) Definitions

(a) Business hours comprise the time from 7:00 a.m. to 10:30 p.m. on working days, with the exception of federal holidays and holidays applicable in Bavaria, Christmas Eve and New Year's Eve.

(b) Unavailability is the period of time during which a service provided by Thomas-Krenn.AG is not available.

(c) Restoration time means the period of time within which a service affected by a disruption has been restored. The customer will be notified in writing on the restoration of a service affected by a malfunction.

(d) Calendar month refers to a month with a calculated 30.5 days, regardless of the actual number of calendar days.

(e) Maintenance window means the period of time during which scheduled and announced work is performed on a service.

(f) Response time describes the period of time between the receipt of a qualified fault report from the customer by telephone, e-mail or ticket and the written confirmation of an existing fault by Thomas-Krenn.AG via e-mail. Response time during business hours is 30 minutes and 120 minutes outside business hours.

 

§2 Services of Thomas-Krenn.AG

(1) Infrastructure-as-a-Service (IaaS) services

Thomas-Krenn.AG provides a platform at one or more locations, with the help of which computing resources (network, RAM, CPU, data storage) can be compiled and operated. The resources provided are exclusively available to the customer and are charged per minute according to the respective valid prices.

IaaS services fall into three categories: controlling, primary and secondary services. Services not listed below fall into the category of secondary services.

(a) Controlling services

(I) API describes interfaces operated by the partner which allow the customer to configure their services. The API is based on a standardized RESTful-HTTP interface.

(II) API CLI describes a command line interface provided by Thomas-Krenn that allows the operation of the partner's API.

(III) API GUI describes a web interface provided and hosted by Thomas-Krenn that allows the operation of the partner's API.

(IV) Automation Services are services operated by the partner that perform certain activities in an automated manner based on criteria defined by the customer. For example, snapshots of individual virtual hard disks can be created and archived automatically, or additional CPU resources can be provided automatically in the event of certain workload parameters (e.g. CPU utilization on a virtual server).

(b) Primary IaaS services

(I) Computing resources are the resources from which a virtual server is composed. These include:

- Processor cores (CPU)

- Memory (RAM)

- Network interface cards (NIC)

- Primary block storage (storage)

(II) Upstream describes the connection between the partner's network and the internet.

(III) Private network describes the connection between the customer's virtual servers via a software-defined network (SDN).

(2) Managed Platform-as-a-Service (PaaS) services

Thomas-Krenn.AG provides an interface at one or more locations that allows the customer to request and access high-quality IT services and programs (e.g. S3 storage, load balance, firewall, message gateway, databases, Kubernetes orchestration, etc.). IT services provided as PaaS are classified as standardized and managed services.

 

§3 Monitoring and availability guarantee

(1) Predictive failure detection

The services operated by Thomas-Krenn are subject to permanent monitoring. A wide range of sensors and monitoring technologies are used to identify malfunctions before they occur (so-called predictive failure detection – PFD) and automatically take suitable measures to move services used by the customer to a zone that is not affected by a malfunction. Further, reactive instruments are used that automatically restore the service used by the customer when a malfunction occurs and, if necessary, automatically alert the partner's corresponding IT experts and involve them in the fault clearance. To ensure PFD, it is necessary for the partner to collect sensor information and process it automatically (so-called machine learning and profiling). In particular, information regarding customer workloads, the behavior of specific workloads, automated operations using the partner's API, the response behavior of hardware and software, hardware and sensor temperatures, power supply readings and statistically relevant data about the behavior of the platform operated by the partner, including PaaS services, is collected. No personal data according to GDPR is collected at any time within the scope of this data collection.

(2) Network monitoring

The partner's upstream is monitored from different regions of the world. In some cases, external service providers are used, which allow the partner's NOC to log a measurement of latencies, packet losses and changes in routing paths. The upstream is considered unavailable once two consecutive checks from at least two different regions of the world have revealed unavailability.

(3) Availability guarantee

(a) The following measurement methods are used:

(I) Activity-based measurements

The number of activities per month, customer, and service are each counted in steps of 10,000 activities and each rounded up to the next 10,000 activities. The sum of the activities is put into the ratio of the failed activities. The calculation results in the percentage of unavailability in the respective month.

(II) Time-based measurements

The sum of unavailability in the respective month is put into the ratio of the theoretically possible availability per month. The calculation results in the percentage of unavailability in the respective month.

(b) The following availability guarantees apply:

Service (type)	Availability	Criterion	Examples
Primary	100%	An interruption in the operation of primary services counts directly as unavailability, unless otherwise agreed.	SLA violated: The upstream is unreachable from at least two different regions of the world for two consecutive measurements.
			SLA not violated: a CPU system of the partner freezes unannounced. The partner's sensor system correctly detects this condition within a tolerance of 120 seconds and performs an autorecovery procedure according to the customer's settings.
Controlling	99.999%	The inaccessibility of API interfaces or non-execution of API commands or automation services not executed on time.	SLA violated: out of 10,000 requests from a customer to the partner's API, more than one error occurs.
			SLA not violated: for every 100,000 API requests, there is one failed API request
PaaS	99.99%	Interruption of the operation or accessibility of the respective PaaS service.	SLA violated: A load balancer service is not available for more than 264 seconds in the respective billing month or the function is disrupted.
			SLA violated: A PaaS database cluster does not respond to queries for more than 264 seconds in a given month.
Secondary	99.9%	Secondary services are not available or generate a non-operational error.	A secondary service is not available for more than 44 minutes in a given month.

§4 Maintenance measures

The partner provides the customer with an Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) architecture based on a so-called zero-downtime architecture. Zero downtime means that the vast majority of maintenance work on the architecture, individual components, provided services or infrastructure can be carried out without affecting the services provided by the partner.

Maintenance work on central components that are used by more than one customer at a time (e.g. storage systems, network systems, central software components) is always announced in advance by the partner. The announcement is made at least three days in advance via the specially operated service portal. Additionally, the partner can inform the customer on request about such work on a case-by-case basis via e-mail to an e-mail address provided by the customer for this purpose. Subscription to these emails can be taken out directly via the service portal operated by the partner. The announcement will always state what consequences or restrictions are to be expected during maintenance work.

Maintenance work on individual components to which only one customer has access (e.g. dedicated hardware) is coordinated with the customer on a case-by-case basis and, if possible, carried out by mutual agreement at a time that is convenient for the customer.

Maintenance work is carried out immediately (even without prior notice) on both central and individual components if events occur that require immediate action (e.g. imminent danger).

 

§5 Credit and capping of credit in case of violation of SLA

(1) Recording of availability and unavailability

The partner automatically and autonomously records SLA compliance for each service. A shortfall in the availability agreed in the SLA leads directly to a credit on the customer account, which is offset against the respective invoice following the credit note. The customer is not obliged to give notice. Only the data collected and automatically evaluated by the partner is decisive for the achievement of the SLA. If any measurements of the customer deviate from the measurements of the partner by more than 10% to the disadvantage of the customer, the parties agree to conduct a joint root cause analysis in order to make deviating measurement methods transparent for both parties and to enable the partner to adopt the customer's method for future measurements and to use it itself. This is to ensure an optimal measurement result at all times.

(2) Cap of credit notes

The amount of cumulative credits are capped at the customer's average monthly revenue of the previous three months, and not more than the customer's total revenue incurred in the calendar year.

(3) Credit note process

In case of violation of the SLA, a credit note is issued automatically. In the case of time-based measurements, the credit is composed of the duration of an unavailability rounded up to 5 minutes, multiplied by a factor of 10 on the charges incurred for all services directly affected.

In case of violation of an SLA related to activity-based measurements, the credits are calculated from the base price per activity, analogous to the time-based measurement with a factor of 10.

 

§6 Miscellaneous

(1) Claims for defects

If the service levels defined in this document are not met, the partner will automatically create a credit note derived in accordance with this document and will credit this to the customer's account no later than in the billing period following the disruption.

(2) Prices, changes, termination

The SLA is provided at no additional cost as part of the services provided by Thomas-Krenn.

(3) Liability

In the event of non-compliance with service levels, the regulations defined in this contract apply. There are no provisions on contractual penalties. For all claims against Thomas-Krenn.AG, the regulations in the current version of the GTCs agreed on with the customer apply exclusively.

 

Version: June 24, 2021