Service Level Agreement (SLA)

Version: 1.0
Last updated: 2 September 2026
Governing language: Dutch. In case of conflict, the Dutch version prevails.

This Service Level Agreement (“SLA”) describes the availability that Thalassa Cloud Services B.V. (“Thalassa”) provides for its public-cloud services and the compensation the Customer may claim when a Service Commitment is not met. This is a product SLA for standardised services. It forms part of the Terms of Service and related terms (“Terms”). By using the Services, the Customer accepts this SLA.

1. Scope

1. This SLA applies to generally available (General Availability) Services. Services and features designated Alpha, Beta, Preview, Early Access, Experimental or similar are not covered by this SLA, unless Thalassa expressly states otherwise.
2. The SLA covers the availability of the infrastructure and managed services provided by Thalassa. Everything that falls under the Customer’s responsibility according to the shared responsibility model, including applications, workloads, configurations and the guest operating system and software within a Virtual Machine, is outside the scope of this SLA.
3. Higher workload availability also depends on the Customer’s architecture choices, such as distribution across Availability Zones and application-level failover.
4. For the Thalassa Cloud platform itself (the central components with which the Customer manages Resources, such as the API, the console and the identity provider), Thalassa targets a monthly availability of 99.9% and monitors this itself via status.thalassa.cloud. No Service Credits apply to the platform. Unavailability of the platform, for example temporarily preventing Resources from being created or modified, does not make existing Resources unavailable.

2. Definitions

1. Services: Thalassa’s public cloud services (IaaS/PaaS), including managed services.
2. Customer: the organisation using the Services.
3. Resource: an individually identifiable component of the Services to which a Service Commitment applies, for example a Virtual Machine, a database instance or a Kubernetes cluster.
4. Availability Zone: a physically separate location within a Thalassa region, with its own power supply, cooling and network, in which Resources are provided.
5. Service Commitment: the Monthly Availability committed by Thalassa as set out in Article 3.
6. Total Time: the number of minutes during which the relevant Resource was active and billed in the calendar month.
7. Unavailable Time: the number of minutes within Total Time during which the Resource was unavailable as described per Service in Article 3, excluding the situations in Article 7.
8. Monthly Availability: the percentage of Total Time during which a Resource was available, calculated under Article 4.
9. Service Credit: a credit in Thalassa Cloud Credits granted under Article 5 when a Service Commitment is not met.

3. Service Commitments

Thalassa commits to the following Monthly Availability per Service:

Services with a Service Commitment of 99.9% are delivered by Thalassa redundantly across multiple Availability Zones. Worker nodes of a Managed Kubernetes cluster are Virtual Machines and are covered by the Service Commitment for Virtual Machines.

A Resource is unavailable when:

1. New generally available Services are automatically covered by a Service Commitment of 99.5%, unless the product documentation expressly states otherwise.
2. The Service Commitment for a High Availability variant applies only where Thalassa offers that variant and the Resource is configured as such. The Customer distributing or combining multiple Resources itself, for example Virtual Machines across multiple Availability Zones, does not make them a single Resource with a higher Service Commitment.

4. Availability calculation

1. Monthly Availability is determined per calendar month and per individual Resource. The availability of different Resources within a project, account or organisation is not aggregated.

2. Monthly Availability is calculated as follows:

   (Total Time − Unavailable Time) / Total Time × 100%

3. A Resource is assessed as a whole. Failure of an underlying Availability Zone, node, replica or other component does not count as Unavailable Time as long as the Resource as a whole remains available.

4. The number of separate incidents is not relevant. All Unavailable Time during the calendar month is added together.

5. The availability of a Resource for the purpose of Service Credits is determined after the Customer submits a claim (Article 6). Thalassa uses available technical data for this, including monitoring, logging, events and platform records.

5. Service Credits

1. Where the Monthly Availability of a Resource is below the applicable Service Commitment, the Customer may claim Service Credits.
2. For each full 0.1 percentage point by which Monthly Availability falls below the Service Commitment, the Customer receives a Service Credit of 1% of the monthly charges of the affected Resource. The deviation is rounded down to full steps of 0.1 percentage point.
3. The maximum Service Credit is 25% of the monthly charges of the affected Resource.
4. Service Credits are calculated solely over the charges of the affected Resource and not over other Resources, the project, the account or the total invoice. For Resources for which no monthly charges are billed, such as a VPC, the Service Credit is nil.
5. Service Credits are granted as Thalassa Cloud Credits, are automatically deducted by Thalassa from a subsequent invoice, are not paid in cash and are not transferable.
6. Service Credits constitute the compensation granted under this SLA when a Service Commitment is not met. No notice of default is required to obtain Service Credits. Any liability of Thalassa is governed by the Terms of Service.

Example. A Virtual Machine has a Service Commitment of 99.5%. Established Monthly Availability is 99.0%. The difference is 0.5 percentage points. The Customer therefore receives a Service Credit of 5% of the monthly charges of that Virtual Machine.

6. Claims

1. Service Credits are not granted automatically.
2. The Customer submits a claim via the service desk no later than 30 days after the end of the calendar month to which the claim relates.
3. The claim must at least state: the relevant account or project; the affected Resource(s); and an indication of the date, time or period during which the Customer experienced unavailability. The Customer need not calculate Monthly Availability or the Service Credit itself.
4. Thalassa investigates the claim and determines Unavailable Time and Monthly Availability from the available technical data. If the Service Commitment was not met, Thalassa calculates the Service Credit under Article 5. Thalassa communicates the outcome via the service desk.

7. Exclusions

In determining Monthly Availability, no Unavailable Time is counted that results from:

1. acts or omissions of the Customer or the Customer’s users;
2. the Customer’s configuration, applications, workloads, scripts or data, or the guest operating system and software within a Virtual Machine;
3. exceeding quotas or capacity as a result of the configuration chosen by the Customer;
4. the Customer stopping, deleting or modifying a Resource;
5. networks or systems outside Thalassa’s responsibility, including the public internet and the Customer’s networks;
6. external services that do not form part of the Service provided by Thalassa;
7. use contrary to the product documentation or the usage rules in the Terms of Service;
8. announced planned maintenance within the announced maintenance window (Article 8);
9. cyberattacks on Thalassa or its suppliers, such as (D)DoS attacks, malicious software or attempts at unauthorised access; or
10. circumstances entirely beyond Thalassa’s control that do not constitute a normal operational risk of a cloud platform, such as government measures, war, terrorism or natural disasters.

Other failures in the infrastructure, datacentre facilities, platform software or managed-service components that Thalassa uses to deliver the Services, including shortcomings of suppliers, are not in themselves excluded from the availability calculation.

8. Maintenance

1. Thalassa performs periodic maintenance to safeguard the security, reliability and continuity of its Services.
2. Planned maintenance that may affect availability is announced in advance via status.thalassa.cloud and, where relevant, via additional communication channels.
3. Announced planned maintenance within the announced maintenance window does not count as Unavailable Time. Unavailability outside the announced maintenance window does count.
4. Where immediate maintenance is necessary due to an acute security, stability or continuity risk, Thalassa may perform emergency maintenance without prior notice. Unavailable Time resulting from emergency maintenance counts towards Monthly Availability, unless another exclusion in Article 7 applies.

9. Miscellaneous

1. Thalassa’s Terms of Service apply to this SLA.
2. In case of conflict between this SLA and the Terms of Service regarding a Service Commitment, the availability calculation or Service Credits, this SLA prevails. Liability and other contractual matters are governed by the Terms of Service.
3. Thalassa may amend this SLA. Amendments are published and notified to the Customer in accordance with the Terms of Service. An amended Service Commitment does not apply to calendar months that ended before the amendment.