SLA comparison

Service Level Agreement Overview

DeltaBlue hosting

Version 1.4

Effective from: 9 September 2024

Service Level Agreement

Subject of this Agreement

DeltaBlue offers an end-to-end solution for websites / applications in its capacity as a hosting provider. This implies monitoring of both machine and application and all interventions needed to keep the application online in optimal conditions (hosting).

This page describes the various Service Levels offered between DeltaBlue and the “CUSTOMER”. It also includes the processes, roles and responsibilities of the entities involved in providing the service.

Overview of included services

Service availability

Availability

Service availability, also known as uptime, is measured and tracked monthly. Service availability is limited to paid services. The required availability of a service can be adjusted on a project/environment basis. This will be offered separately based on requirements and scope.

Mean Time to Repair

The mean time to repair, or MTTR for short, or Recovery Time Objective (RTO) is the average time between the identification of an incident and the resolution of an incident. This includes individual incidents, as well as complete rebuilding of an environment.

Recovery point objective

Recovery point objective or recovery point objective expresses what the maximum allowable amount of data loss is, due to an error.

Availability overview

* Business days (Monday - Friday), weekends and holidays included

** Extended Business Days (Monday - Friday) from 8:00 a.m. CEST to 8:00 p.m. CEST

SLA Compensation

In the event that DeltaBlue fails to meet or exceed the service availability as determined by the selected service level, the following compensation schedule will apply: A = (L - P)

Percentage below target	Credit to be applied on the next monthly invoice of Q
0.5% ≥ A	5%
0.5% < A ≤ 1%	10%
1.0% < A ≤ 2.5%	15%
2.5% < A ≤ 5%	25%
5.0% < A	50%

• A = Departure from service availability as determined above
• L = The availability of the service as defined above
• P = The actual percentage of availability
• Q = The monthly fee charged by DeltaBlue for the relevant services.

The compensation awarded shall not exceed 50% of the monthly fee for the service in question.

	Standard	Advanced	Advanced+	Premium	Enterprise
SLA compensation	NO	NO	NO	YES	YES

Support

Critical vs. non-critical support

To pursue optimal support, we distinguish between “critical” and “non-critical” support.

Critical Support

Critical support includes all problems that disrupt the correct operation of the DeltaBlue platform and require immediate attention to the correct operation of the services in question. This includes the malfunctioning of Cloud infrastructure, network and provisioning systems leading to a proven interruption of the services offered. This refers to the errors or failures related to the operational execution of customer applications, where the underlying error can be directly related to the incorrect functioning of the platform. Examples:

• Failure of the application service to connect properly to the database service, due to a network fault in the platform.
• An application, which cannot generate a pdf document because of an underlying storage problem. This excludes exceeding storage quota’s.

These services are monitored 24/7. In the event that an error is detected, corrective actions will be taken within the agreed upon SLA parameters.

Non-critical support

All other questions are by definition non-critical questions. This includes:

• All questions related to the use of the services offered
• Software support
• Configuration changes (not needed to resolve critical issues)

Overview

Critical support should always be requested via a phone call. Additional information can be delivered via e-mail (logs, extra info, …). If critical support can only be requested via e-mail, the response time baseline only starts to run from the moment an employee has confirmed that a ticket has been opened (i.e. not only through automatic notification of the ticket creation).

Non-critical support can be requested by ticket.

	Standard Support	Advanced Support	Advanced Support+	Premium Support	Enterprise Support
Support channel	tickets	tickets	tickets	tickets, phone	tickets, phone, live chat (Slack)
Direct access to Engineer	NO	NO	NO	YES	YES
Direct access to Architect	NO	NO	NO	NO	YES
Critical Support
Support hours	Working days***	Working days***	Working days***	24x7*	24x7*
Response Times	< 1 hour	< 1 hour	< 1 hour	< 30 minutes	< 30 minutes
MTTR	4 hours**	3 hours**	3 hours**	2 hours**	Bespoke
Recovery Point Objective	24 hours	24 hours	24 hours	24 hours	Bespoke
Non-Critical Support
Support hours	8x5	12x5	12x5	12x5**	12x5**
Response Times	Next business day	< 1 business day	< 1 business day	< 1 business day	< 1 business day
# of tickets (platform error)	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
# of tickets (customer error)	0	Unlimited	Unlimited	Unlimited	Unlimited

* All days (Monday - Friday), weekends and holidays included

** Extended Business Days (Monday - Friday) from 8:00 a.m. CEST to 8:00 p.m. CEST

*** Working days (Monday - Friday) from 9 am CEST to 6 pm CEST, excluding legal holidays

Service Desk

The service desk is the single point of contact for all service requests. Service requests are divided into requests for modifications (RFC), critical and non-critical tickets.

Contact details

	Details	Period
Phone number:	+32 12 69 55 55	During weekdays for all incidents and service requests during business hours.
24h/7 Hotline:	Log in to your account, go to account details and support.	24/7/365 Remarks: Only available for Premium and Enterprise SLA customers
E-mail:	[email protected]	24x7, for all incidents
Ticketing:	https://support.delta.blue	24x7, for all incidents

Support Policy

In Scope

Installation and configuration problems

• Installation of application dependencies that are non-specific to the application or project
• Recommended procedures for configuring supported application dependencies
• General questions about supported software packages

Troubleshooting

• Identification of problems that cause a system application to not function
• Providing solution to known problems
• Answering general user questions, and providing references to documentation
• Troubleshooting for supported software packages that exhibit erratic or faulty behavior independent of the “CUSTOMER’s” application, for example, failure of a database server or web server to function

Out of Scope

DeltaBlue’s technical support services do not include the following tasks:

• General troubleshooting of user applications
• Rewrite application code
• Modifying and/or patching 3rd party or Open Source software.

Incident, Problem and Change Management

The incident processes within DeltaBlue are organized according to the ITIL methodology.

There is a distinction between incidents and problems.

Incident

An incident is defined as an unplanned interruption or reduction in the quality of a service (a service interruption). The objective of the Incident Management process is to restore normal service operation according to the schedule defined in this SLA, and to minimize the adverse impact on business operations, thereby maintaining the agreed upon service “Levels”. “Normal Service Operation” is defined as service within SLA limits.

Problem

A problem is the cause of one or more incidents. The cause is usually not known at the time a problem is recorded and the DeltaBlue is responsible for further investigation.

Change Management

“Change Management” is responsible for managing change processes with changes such as:

• Platform functionality not yet available in the user interface
• Specific network implementations
• Customer specific patches and software
• The CAB (change advisory board) will evaluate all changes before they are implemented.

In the event of an incident, the customer should contact the Service Desk and provide all relevant information regarding the business impact and urgency of the reported incident to ensure that the incident is correctly classified. With this information, and in accordance with the “CUSTOMER”, the Service Desk will create an incident for the customer’s call and assign a level of urgency as set forth below:

The service desk records the customer’s call in the ticketing system, carefully documents it and assigns it to the appropriate support team for further follow-up.

The service desk will simultaneously confirm to “CUSTOMER” that the call has been registered and provide a ticket number. This number serves as a unique identifier for the incident and will be used in all further related communications between “SUPPLIER” and “CUSTOMER”.

Throughout the resolution process, the incident ticket continues to be updated with status information. The “CUSTOMER” is informed about these updates via automatically generated email notifications thru the ticketing system.

Monitoring and interventions

DeltaBlue has developed a scalable distributed monitoring environment that scales with the size of the platform. In case of technical problems, the necessary technical people are automatically notified, 24/7.

System monitoring

The following list is a summary of the system parameters that can become active:

Bandwidth, cpu context switches, cpu load, cpu frequency, disk i/o, DNS resolution, system interrupts, disk i/o latencies, kernel version, system load, container status, memory usage, network connectivity, time synchronization, memory paging, process count, swap usage, number of network connections, threads, uptime, logged in system users, zombie processes.

Application Monitoring

Availability of applications can be monitored via http based checks. Urls added to an application will be monitored automatically for responding with a valid HTTP status code (2xx,3xx,4xx).

Health checks urls should be used to validate the correct functionality of applications.

Backups

Based on the SLA levels, backups will or will not be part of the service level. For more information, please contact our support.

Backup	Standard	Advanced	Advanced+	Premium	Enterprise
Backups *	Not included *	Not included *	Included up to 250GB *	Included up to 2TB *	Included
Interval	/	/	1x / day	1x / day	2x / day
Retention period	/	/	Daily: up to 7 days Weekly: up to 2 weeks	Daily: up to 14 days Weekly: up to 1 month	Daily: up to 21 days Weekly: up to 1 month
Retention number	/	/	9 backups (7 x 1 + 2 x 1)	18 backups (7 x 2 + 4 x 1)	25 backups (7 x 3 + 4 x 1)
Time frame	/	/	01:00 – 04:00	01:00 – 04:00	Bespoke

* Customers can configure additional backups within the Platform for each application using the build-in Backup feature.

Interval

Backups are made automatically 1x per day, each time during a fixed time period. (See table above) For Enterprise SLA customers, this can be customized, for example, between: 01:00 and 04:00 in the morning and 12:00 and 15:00 in the afternoon.

Retention period

The retention period indicates how much time a specific backup will be available for restore.

For Advanced+ SLA customers:

• Daily backup: retention of 7 days
• Weekly backup: retention of 2 weeks

For Premium SLA customers:

• Daily backup: retention of 14 days
• Weekly backup: retention of 1 month (4 weeks)

For Enterprise SLA customers, this can be customized.

Retention number

According to the retention period and interval, this means that a fixed number of backup sets are always kept.

Software updates

Software updates, or patching, includes all tasks to ensure that all systems remain protected from security vulnerabilities.

The hosting platform is continuously updated without downtime. Higher impact updates are scheduled outside business hours and are communicated beforehand. Critical patches are applied within 24 hours.

Server and container updates

Servers and containers with customer applications or data consist of 3 layers:**

1. the “base” layer. The base layer contains all the system files needed to run the technology within the application, such as the system library and system tools. The base layer of each container will be updated at least once every three months with the latest stable patches and security patches. In the case of critical bug fixes or security patches, the base layer will be updated within 24 hours.

DeltaBlue bases the classification of urgency of patches and updates on the upstream distribution provider. For Ubuntu-based containers, this is “Canonical”.

2. The “technology” layer. The technology layer contains all the files that are part of the technology used. For example, MySQL files or Apache files. The technology layer of each container is updated at least once every three months with the latest stable patches and security patches. In case of critical bug fixes or security patches, the base layer is updated within 24 hours.

DeltaBlue relies on the upstream distribution provider for the classification of urgency of patches and updates. For Ubuntu-based containers, this is “Canonical”. If the software is not distributed by a distribution vendor, but directly by the software vendor, DeltaBlue will use the software vendor as the basis for the classification of urgency of patches and updates.

3. The “application” layer. The application layer contains all code files and content added or generated by the customer or customer application.

For example: Symfony PHP files or NodeJS files.

It is the responsibility of the “CUSTOMER” or its software vendor to maintain and keep their code and files up to date.

Application updates

Application patching is the responsibility of the customer or its software vendor. DeltaBlue does not perform updates or validation on the customer’s application setup. This includes all application code and frameworks provided or created by the customer or its application vendor.

Security

The hosting platform is designed to protect customers from threats by:

• Implement security controls at every layer, from host (physical or virtual) to application.
• Isolate customer applications and customer data.
• The ability to quickly perform security updates without customer interaction or minimal service interruption.

Technically, this translates into:

• Segregation of customer data
• Segregation of network traffic
• Process Isolation
• Inbound and outbound traffic is handled through different routes