note This is a reference document, not a contractual document. If you are a Platform.sh Enterprise Customer please refer to your signed contract for the specifics of our engagement.
Platform.sh agrees to host and maintain Subscriber’s websites and associated development environments on the Platform for the term of the Agreement and in accordance with the service level standards set out below. Platform.sh shall use commercially reasonable efforts to prevent unauthorized access to its infrastructure and shall promptly notify Subscriber of any known security breaches.
Service Credits are calculated as a percentage of the total charges paid for Platform use by the affected live sites for the monthly billing cycle in which the Service Unavailable status occurred, in accordance with the schedule below.
- Less than 99.99% but equal to or greater than 99.95%: 5%
- Less than 99.95% but equal to or greater than 99.0%: 10%
- Less than 99.0%: 30%
Platform.sh will apply any Service Credits only against future Platform payments otherwise due. Platform.sh may at its discretion issue the Service Credit to the credit card used by the Subscriber to pay for the billing cycle during which there was Service Unavailable.
Service Credits will not entitle Subscriber to a refund or other payment. A Service Credit will be applicable and issued only if the credit amount for the applicable monthly billing cycle is greater than one Euro (€1 Euro). Service Credits may not be transferred or applied to any other account. Unless otherwise specified in writing, or by law, Subscriber’s sole and exclusive remedy for any unavailability, non-performance, or other failure by Platform.sh to provide Platform-related Services is the receipt of an eligible Service Credit.
The following situations are not covered by the Platform.sh Enterprise SLA:
- The brief period during a deployment in which the application has been taken offline in order to mount the new application slug and run the deploy hooks. Your application will be unavailable during this time, but the window can be minimized by ensuring that your deploy hooks run quickly.
- Outages caused by high-traffic situations in cases where the customer opted to not allow Platform.sh to upsize the Enterprise Cluster unilaterally.
- Outages caused by errors in application code, including custom Fastly VCL configuration under the control of the customer.
- Outages caused by errors in the
- Development environment outages are not considered an SLA violation if the Production instance is still running properly.
Typical maintenance does not require taking your application or hosting cluster offline. This is one of the benefits of our N+1 architecture. During routine maintenance each server will be removed from rotation at the load balancer, upgraded, and placed back into rotation. Then the operations engineer will move to the next node in your cluster and perform the same procedure. The overall process is very much the same as outlined in the scaling procedure, but software updates are applied rather than scaling of your cluster’s capacity.