Service Levels

VSHN operates services 24/7 and ensures availability. With the service level Guaranteed Availability an availability guarantee is agreed upon (SLA). An availability guarantee is applicable per service instance.

These service levels are not yet available for every product. Please consult the product documentation to see if they’re already supported.

1. Offering

We offer two service levels: Best Effort and Guaranteed Availability.

Best Effort Guaranteed Availability

Availability Guarantee

None

99.99%

Service Credits

None

Yes

Service Maintenance

Continuous

Choice of pre-defined maintenance window times

[Support and reaction times]

see Support Plans

see Support Plans, priority support plan recommended

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.

2. Availability Guarantee

Each product defines its Service Level Indicators (SLIs) which the guarantee applies to:

Application Marketplace

Please refer to the individual service description on the list of AppCat Services.

Managed OpenShift

Details are documented in the VSHN Knowledge Base.

Server based Managed Services

Please refer to the individual service description on the list of Managed Services.

Check What does SLI / SLA / SLO mean? to learn more.

3. Service Credits

In the event that the guaranteed availability wasn’t met during a calendar month, you will be eligible to receive service credits.

Monthly availability Service credits

Less than in the detailed service description but equal to or greater than 99.0%

10%

Less than 99.0% but equal to or greater than 95.0%

25%

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 the guaranteed availability in a billing cycle.

3.1. Service Credit Request

If the SLA 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.

4. Applicability

The service levels are applicable to all VSHN services. Exceptions are documented in the service specific documentation.

5. 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 the guaranteed availability service level:

  • 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.

6. Monitoring and Alerting

VSHN monitors services 24/7 and proactively reacts on SLA-relevant alerts.

7. Availability Reporting

VSHN continuously measures service availability and can produce reports on request.

8. 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.

9. 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.

10. Legacy Service Levels

These are the legacy service levels and are documented here for historical reasons.
Zero Standard Professional Premium

Availability Guarantee

none

99.0% / mth

99.5% / mth

99.9% / mth

Included SLA

none

Standard

Professional

Premium

Maintenance

  • Customer’s responsibility

  • Unattended

  • Fixed maintenance window

  • Unattended maintenance

  • Fixed maintenance window

  • Unattended but monitored maintenance

  • Flexible maintenance window

  • Attended and monitored maintenance

An availability is guaranteed on the VSHN services only, notably the following is excluded:

  • Underlying infrastructure and network.

  • For a complete list, see SLA. To have an overall availability guarantee, the customer (directly or via VSHN) must have a matching SLA option with the IaaS provider and other relevant systems that impose a risk on availability.

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 about the old / legacy service levels?

There are two other service levels which VSHN offered in the past:

Reactive / Proactive SLA

This was the first SLA offering of VSHN and only specified how VSHN can be contacted and if we fix issues proactively outside office-hours. These SLAs aren’t offered anymore to new customers. The successor to them are Support Plans.

Standard / Professional / Premium

These are the service levels of VSHN Managed OpenShift, documented as Legacy Service Levels above. They were only available for this product.

The old service levels will be migrated to the service levels on this page as the contract allows, and individually per customer.

11.3. 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.4. 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.5. 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.6. 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.7. Is a deviation from the default guarantee possible?

A deviation from our default availability guarantee is usually not intended.

11.8. Can I have a Guaranteed Availability service on a Best Effort cluster?

No, that’s not possible. As service running and a cluster must have the same or a lower service level. For example, on a cluster with Guaranteed Availability service level, a service on this cluster can have the Best Effort service level. On the other hand, on a cluster with Best Effort service level, a service on this cluster cannot have the Guaranteed Availability service level.