Service Levels
VSHN operates services 24/7 and ensures availability. With a guaranteed service level profile, an availability guarantee is agreed upon (SLA). An availability guarantee is applicable per service instance of products or defined building blocks in the scope of custom Solutions.
| These service levels are not yet available for every product. Please consult the product documentation to see if they’re already supported. |
1. SLA Profiles
For products using profile-based SLA targets, VSHN offers the following profiles:
-
Baseline -
99.9% - Business Hours -
99.9% - 24/7 -
99.99% - 24/7
1.1. Legacy Label Mapping (Deprecated)
Legacy labels are deprecated and replaced by profile-based SLA targets.
| Legacy label | Current SLA profile mapping | Migration path |
|---|---|---|
Best Effort |
Baseline |
Mapped directly to |
Guaranteed Availability |
One of the following, depending on contract scope:
* |
Existing customers are mapped to an equivalent profile based on current contract, support scope, and service-level commitments.
In most cases, |
Any changes or upgrades to SLA profiles will be coordinated with the customer during contract renewal or amendment.
1.2. Feature Scope Matrix
For products using profile-based SLA targets, the following scope matrix applies:
| Scope Item | Baseline | 99.9% - Business Hours | 99.9% - 24/7 | 99.99% - 24/7 |
|---|---|---|---|---|
Availability target |
No formal uptime commitment |
99.9% |
99.9% |
99.99% |
Measurement window |
No contractual uptime measurement |
Office Hours (Mon - Fri 09:00 to 18:00 CET / CEST; see Support Availability) |
24/7 |
24/7 |
Planned maintenance treatment |
Excluded |
Excluded |
Excluded |
Excluded |
Response target |
Not included |
2h during business hours |
2h 24/7 |
1h 24/7 |
Incident reporting |
Not included |
Available on request |
Available on request |
Mandatory RCA within 5 days |
Service-credit eligibility |
No |
Yes |
Yes |
Yes |
SLA profiles define availability measurement, service-credit eligibility, and incident commitments for the covered service instance. Support plans define channels, engagement window, access model, and escalation scope. For 99.9% - 24/7 and 99.99% - 24/7 SLA profiles, the selected support plan must include 24/7 support availability unless contract scope explicitly defines equivalent coverage. See Support Plans.
|
2. Offering
Service levels are offered per service instance and depend on the product scope. Use the Feature Scope Matrix for profile-specific commitments. Support channels, access model, and escalation scope are documented in Support Plans.
The availability guarantee applies to the services provided by VSHN only, see Exceptions to Availability Guarantee for a list of exceptions. The service level applies to an individual service instance.
3. Availability Guarantee
Each product or Solution Building Block defines its Service Level Indicators (SLIs) which the guarantee applies to:
- Application Catalog
-
Please refer to the individual service description on the list of AppCat Services.
- Managed OpenShift
-
Our Service Level Agreements (SLAs) reflect actual service availability from the user’s perspective. We base our measurements on whether workloads are truly reachable, not just on technical indicators. SLA breaches are only recorded when there is a real impact on accessibility.
This approach ensures our service levels are transparent, meaningful, and aligned with what matters to our customers.
Details are documented in the VSHN Knowledge Base.
- Solution Building Blocks
-
Please refer to the relevant Solution Building Block used in your documented solution.
| Check What does SLI / SLA / SLO mean? to learn more. |
4. Service Credits
If a service instance with an SLA profile target that warrants Service-credit eligibility does not meet its contractual monthly availability target, you may be eligible for service credits.
Service instances with profile Baseline are not eligible for service credits.
For eligible profiles, the highest applicable service-credit tier applies.
| SLA profile | Monthly availability | Service credits |
|---|---|---|
99.9% - Business Hours or 99.9% - 24/7 |
Less than 99.9% but equal to or greater than 99.0% |
5% |
99.9% - Business Hours or 99.9% - 24/7 |
Less than 99.0% but equal to or greater than 95.0% |
10% |
99.9% - Business Hours or 99.9% - 24/7 |
Less than 95.0% but equal to or greater than 90.0% |
25% |
99.9% - Business Hours or 99.9% - 24/7 |
Less than 90.0% |
100% |
99.99% - 24/7 |
Less than 99.99% but equal to or greater than 99.9% |
5% |
99.99% - 24/7 |
Less than 99.9% but equal to or greater than 99.0% |
10% |
99.99% - 24/7 |
Less than 99.0% but equal to or greater than 95.0% |
25% |
99.99% - 24/7 |
Less than 95.0% |
100% |
Service credits are calculated as a percentage of the charges paid by the customer for the service that did not meet its contractual availability target in a billing cycle.
4.1. Service Credit Request
If the contractual SLA profile target wasn’t met, the customer needs to contact VSHN within 10 days to request the service credit. VSHN will determine the availability during the disputed period and assesses the situation.
Should VSHN conclude that the dispute was in order, the applicable service credit will be deducted from future invoices. The credits may not be transferred or exchanged for cash or other forms of payment.
5. Applicability
The service levels are applicable to VSHN services where they are explicitly offered in product documentation. Product-specific documentation can define availability targets and deviations.
6. Service Maintenance
Services need to undergo regular maintenance to guarantee a good service.
We offer the following pre-defined maintenance window times (all times in CET/CEST) for services with explicit SLA profile commitments:
-
Monday afternoon: 13:00 - 18:00
-
Tuesday morning: 10:00 - 12:00
-
Tuesday afternoon: 13:00 - 18:00
-
Tuesday night: 22:00 - 02:00
Maintenance can be carried out anytime during these time windows, there is no guaranteed starting time.
Maintenance work which has to be carried out in time windows which are during nighttime in the CET/CEST time zone will be carried out by VSHN Canada.
(Excluding public holidays in the canton of Zurich, Switzerland)
If a service offers other maintenance window options, it’s defined in the respective service description.
- Maintenance with expected service interruption or breaking change
-
If maintenance work on a service could cause downtime or changes behavior of a service, the customer is informed at least 7 days in advance. This kind of maintenance is conducted during low-frequency time (usually in the night). The exact time is communicated in the maintenance announcement.
- Maintenance without expected service interruption
-
This work is carried out whenever needed without prior announcement.
- Emergency Maintenance
-
There might be a reason to conduct maintenance as soon as possible, maybe because of a critical security issue which requires immediate action. These kinds of work will be announced at least 1 hour before if there is an expected service interruption.
7. Monitoring and Alerting
VSHN monitors services 24/7 and proactively reacts on SLA-relevant alerts.
8. Availability Reporting
VSHN continuously measures service availability and can produce reports on request.
9. Constraints
- Service period
-
The availability is calculated per calendar month while the service was active. If the service only was active a fraction of a month, the availability guarantee applies to the time when the services was active.
- Effort taken for availability
-
VSHN will use commercially reasonable efforts to make instances available.
10. Exceptions to Availability Guarantee
In calculating of the effective availability, the following exceptions are not considered:
-
Time periods during which previously announced maintenance work is carried out.
-
Availability of third-party and customer infrastructure and services (including cloud and network providers).
-
A change commissioned by the customer or carried out by the customer himself and not approved by the provider, which leads to the failure of the service.
-
An error that is not attributable to the service provided by the provider (e.g. lack of availability of a third-party provider).
-
An error that can be traced back to the general operational risk of an Internet connection (e.g. impairment by DoS attacks, etc.).
-
Changes to devices, connections, network plans, applications operated by the Provider on behalf of the Customer that were not carried out by the Provider.
-
The customer has reported an error, although none was present.
-
Errors within the software, provided that these do not affect the basic characteristics necessary for the provision of the service.
-
Errors within the software that relate to individual functional characteristics of the software but do not reduce the availability of the contractually agreed service, do not reduce the availability and are not classified as Critical.
-
Failures caused by configurations made by the customer.
-
Lack of incident resolution participation by the customer if there is a need for involvement.
11. FAQ
11.1. To which products are these service levels applicable?
These service levels apply to all VSHN products which are offered as a managed service. A product can specify deviations from this definition, for example define a different availability guarantee.
11.2. What does SLI / SLA / SLO mean?
It’s not easy to understand these three abbreviations. They are always tight together and form a triple: An SLA relates to an SLO and an SLI. Therefore, a service can define multiple of these triples.
- SLA - Service Level Agreement
-
The contractual agreement of service availability, including a definition of what happens then the agreement isn’t met.
- SLO - Service Level Objective
-
A usually more stringent objective of service availability, to meet the agreed service availability and have some wiggle room in the form of an error budget. We’re using them solely for internal purposes and don’t expose them.
- SLI - Service Level Indicator
-
The actual measurement to which the SLO and SLA applies to.
Further external resources on this topic:
11.3. What exactly is being measured for the SLA?
This depends on the product and is defined in detail per product. The product specifies what availability exactly means.
11.4. How does the availability guarantee influence the architecture?
The availability guarantee can have an influence on the architecture of a service (for example clustering). This is defined per product.
11.5. Does the cloud provider’s availability influence the service availability guarantee?
We can’t guarantee a higher availability than the underlying platform offers. If the platform doesn’t provide the same or a higher availability guarantee than we do, we will adjust our guaranteed availability accordingly.
11.6. Is a deviation from the default guarantee possible?
A deviation from our default availability guarantee is usually not intended.
11.7. Can I combine services with different SLA profiles on one cluster?
Yes, but only in one direction: a service instance can use the same SLA profile as the cluster or a lower one.
For example, on a cluster with profile 99.9% - 24/7, a service on this cluster can use profile Baseline.
On the other hand, on a cluster with profile Baseline, a service on this cluster can’t use an SLA profile with availability target.