Service Level Agreement and Support Policy

This SLA and Support Policy applies to Enterprise and Elite tier services only.

Capitalized terms not defined in this SLA & Support Policy have the meaning given to them in the Order Form or Enterprise Terms.

1. Service Level Agreement

1.1.  Definitions

“Monthly Uptime Percentage” means the percentage derived by subtracting from 100 the percentage of Service Unavailability minutes during the month.

“Service Credit” means a percentage of the Subscription Fee to be credited to Customer if Platform.sh fails to meet the Service Level agreed in 1.2 below. Service Credit is calculated based on the monthly Subscription Fee due for the environment in production suffering from the Service Unavailability status, as defined below.

“Service Levels” means the service levels set out in 1.2 below.

“Service Unavailability” means the unavailability of the hosting infrastructure of Customer’s Projects on production environment, due either to errors or failures in the hosting stack or lack of network connectivity to the Internet.

1.2.  Service Levels and Service Credits

1.3.  Service Level  exclusions

1.3.1.  The Service Levels identified above do not apply to any Service Unavailability, suspension or termination of the Services caused by any of the following:

1.3.1.1. Factors outside of the reasonable control of or not directly imputable to Platform.sh, including but not limited to any force majeure event listed in this Agreement, internet access, or related problems beyond the software and server instances directly maintained by Platform.sh;

1.3.1.2. Problems resulting from any act or omission of Customer, including errant or problematic application code deployed into an environment;

1.3.1.3. Issues resulting from Customer’s equipment, software or other technology and/or third party equipment, software or other technology (other than third-party equipment directly maintained by Platform.sh);

1.3.1.4. Issues that affect non production environments (e.g.development and/or staging related environments, etc);

1.3.1.5. Services that are not essential to the uptime of the hosting infrastructure of the Project in production environment (e.g. Console, CLI, APIs for the control plane, user authentication, etc);

1.3.1.6. Issues that result from any act or omission of the Platform.sh support team at the request of Customer (e.g. downtime caused by the refusal of Customer to increase the resources allocation on a Customer Project);

1.3.1.7. Issues arising from suspension and/or termination of Customer’s right to use the Services in accordance with this Agreement;

1.3.1.8. Customer-caused unavailability such as missing content, errors caused by Customer code or application configuration errors, or usage capacity in excess of the Customer purchased amount;

1.3.1.9. Service Unavailability due to maintenance operations. Platform.sh reserves the right to interrupt part or all of the Services to perform a technical intervention for the purpose of ensuring the proper operation of the Services, and the safety and stability of the infrastructure behind the Services. Platform.sh will make commercially reasonable efforts to limit the occurrence and duration of the interruption and, where feasible, will publish notifications of upcoming scheduled maintenance operations on https://status.platform.sh/ at least 5 calendar days ahead of the maintenance date. Customer can also subscribe to updates and be notified by email on upcoming and ongoing maintenance operations.

1.3.2. When factors causing the Service Unavailability status cannot be clearly imputed to Platform.sh, Platform.sh may, on a case-by-case basis and in its sole discretion, grant Service Credits.

1.3.3. Unavailability of some specific features or functions within a Project in production, while others remain available, will not constitute Service Unavailable status, so long as the affected features or functions are not, in the aggregate, material to the Project or the Services as a whole.

1.4.  Service Credits

1.4.1. Customer’s sole and exclusive remedy for any Service Unavailability, non-performance, or other failure by Platform.sh to provide Services is the receipt of a Service Credit.

1.4.2. Service Credits will only be applied against outstanding invoice or future Subscription Fees due  and will not entitle Customer to a refund or other payment; except that in the event that Customer is entitled to a Service Credit on termination of the Agreement, Platform.sh will refund Customer in the amount of the Service Credit within thirty (30) days of a request by the Customer to do so.

1.4.3. Should Platform.sh fail to provide Monthly Uptime Percentage of at least 97% for three (3) successive calendar months, Customer may terminate this Agreement immediately on notice to Platform.sh and receive a cash refund in the amount of the current Subscription Term’s prepaid Fees proportionate to the unexpired portion of the Term.

1.4.4. To receive a Service Credit, Customer must submit a claim by opening a support ticket prior to the end of the second month after which the incident occurred and must include:

1.4.4.1. The words “Service Credit Request” in the subject line;

1.4.4.2. The dates and times of each Service Unavailable incident being claimed;

1.4.4.3. The affected Service Project ID;

1.4.4.4 The request logs that document the errors and corroborate the claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks).

1.4.5. If the Monthly Uptime Percentage of such a request is confirmed by Platform.sh and is less than the Service Level, Platform.sh will issue the Service Credit within one month following the month in which the request is confirmed. Failure to provide the request and other information as required above will disqualify Service Credit eligibility.

2. Support terms

2.1.  Procedures and Response Times

2.1.1. Login. Users will be granted access to the support ticketing and issue management system (“Support Portal”).

2.1.2. Initiation of Support Tickets and Ticket Workflows. Tickets are initiated by the Users through the Support Portal and must be submitted separately for each Project and/or issue. They should include:

2.1.2.1 Description of the issue or request, including identification of Supported Modules;

2.1.2.2. Description of the desired state or outcome;

2.1.2.3. Steps necessary to demonstrate or reproduce the issue;

2.1.2.4. Initial Indication of Priority Level (see descriptions of P1 Urgent, P2 High, P3 Normal or P4 Low in 2.4.4. below)

2.1.3. Ticket status. Through the Support Portal, Platform.sh will provide updates on investigation progress and any change of status. Statuses include:

2.1.3.1. New. Tickets not yet reviewed.

2.1.3.2. Open. Analysis in process.

2.1.3.2. Pending. Tickets that are awaiting feedback or other progress from Customer based on information required, or recommendations made, by Platform.sh.

2.1.3.4. Scheduled / On Hold: Events that are requested or scheduled to be executed within the next 72 hours will be marked with this status and will be actioned at the requested time. 

2.1.3.5. Solved. Tickets that have reached a conclusion either through resolution of the issue or determination that no further work is warranted.

2.2. Included Services

2.2.1. Support is available for all Customer environments hosted on Platform.sh (production, staging and development environments) as set out in this SLA & Support Policy (see exclusions in Section 2.3, below). P1 Tickets are only applicable to live, production environments. Support is only available for repeat or systemic issues or errors.

2.2.2. Support includes the following:

2.2.2.1. Response. Platform.sh will respond to and make commercially reasonable efforts towards resolving submitted support tickets. Responses will be addressed within the timeframes and allowances corresponding to the Customer’s purchased subscription level and Support Tier.

2.2.2.2. Post-Issue Analysis. For Enterprise and Elite support services, Platform.sh will use commercially- reasonable efforts to provide post issue analysis upon request following the conclusion of Platform.sh specified Priority 1 (“P1”) tickets only. Customers must so request within 14 calendar days of the ticket being closed, via an update to the original Priority 1 ticket. Customers will be provided a written summary of no more than 500 words in an attachment to the original ticket. Code samples, when included, are not counted towards such limits. The summary will include, as applicable, an explanation of the circumstances, change, or context that caused the issue, or business practices that resolved the issue, and recommendations for prevention of future instances. Depth of analysis is at the discretion of Platform.sh. No additional efforts on the issue will be undertaken.

2.3.  Excluded services

2.3.1. Except as expressly agreed in writing by Platform.sh, the following are excluded from Support:

2.3.1.1 P1 Support excluded for Non-Production, Development, or Preview environments or other functionalities. Staging environments, “sandbox” Projects, and other sites related to the development of a production Project are not eligible for P1 Support.

2.3.1.2. No support to  end-users of Customer’s application. Support for end-users of Customer’s applications hosted on Platform.sh will be provided exclusively by Customer.

2.3.1.3. Training and Consulting. Support related to the application implementation, standard usage, and project consulting is not provided unless specifically identified and itemized on the Order Form or specific statement of work.

2.3.1.4. Hardware, operating system, third-party software, databases, and networks. No support relating to installation, configuration, use, maintenance, or functionality of non-Service hardware, operating systems, third-party software, databases networks, or other enabling technologies is provided.

2.4.  Support Hours and response times

2.4.1. Support hours. Support begins on the Subscription start date  as stated in the Order Form, or another date as mutually agreed to by both Parties, and will expire on the last day of the Subscription Term or the then current Renewal Term. Support tickets will be addressed 24/7/365 in order of the  priority level and support tier.

2.4.2. Response times: Support tickets will be addressed according to the response times for the relevant support tier as set forth in the table below:

2.4.3. Regular Support Hours are as follows: from 00:00 UTC to 23:59 UTC Monday to Friday.

2.4.4. Priority Level: Priority levels referred to in this SLA and Support Policy are are defined as follows:

2.4.4.1. Priority 1 Urgent (P1) - P1 is a catastrophic production problem that severely impacts the Customer’s production systems, or because of which Customer’s production systems are down or not functioning, or that results in a loss of production data and no workaround exists. Platform.sh will make continuous efforts, with appropriate escalation to senior management, to provide a resolution.

2.4.4.2. Priority 2 High (P2) - P2 is a problem in which the Customer’s system is functioning but in a reduced capacity, or the problem is causing significant impact to portions of business operations and productivity, or the software is exposed to potential loss or interruption of service. Platform.sh will make continuous efforts to provide a resolution.

2.4.4.3. Priority 3 Normal (P3) - P3 is a medium- to low-impact problem that involves partial and/or non-critical loss of functionality, or that impairs some operations but allows the Customer’s operations to continue to function. Problems for which there is limited or no loss of functionality or impact to the Customer’s operation and for which there is an easy workaround qualify as P3. Platform.sh will use reasonable efforts to provide a resolution in time for the next minor release of the software.

2.4.4.4. Priority 4 Normal (P4) - P4 is a low- to very-low impact problem, or general question that does not impair the Customer’s operations.

2.4.4.5. Blackfire support tickets will be treated as Priority 3 Normal (P3) tickets.

2.4.5. Customer acknowledges that response targets for the relevant support tier as per the table above are response targets only and not resolution targets. Platform.sh sets no target and makes no guarantee or representation to the Customer regarding resolution times of support tickets.

3.Assistance and professional services

3.1.Onboarding

3.1.1. Platform.sh is not traditional managed hosting. It is an entirely new way of developing and maintaining Customer's applications. By definition it brings workflow and process changes to the customer’s organizations. These changes can be minor or major depending on how success is defined during the sales process, but it is during the onboarding period that these workflow and process changes are put into practice. Onboarding is mandatory for Dedicated plans and for new Enterprise and Elite customers.

3.1.2.It includes the following:

3.1.2.1. Training and Orientation, lasting 2 weeks beginning at contract signing:

• 30 minute welcome meeting consisting of a Question and Answer session on training materials, onboarding processes, and introduction to Platform.sh onboarding team
• 4 total twice-weekly meetings for any further hands on assistance with setup or training. These will be scheduled in the initial welcome meeting.

Note: this phase may be skipped for existing customers.

3.1.2.2. Project development or migration:

• This period can last anywhere from a few days to several months depending on the project.
• Platform.sh onboarding staff does not migrate Customer applications. Rather, this is the period used for more in depth training and (re)definition of Customer workflows and processes. To this end, it is imperative that sufficient Customer development staff time is allocated. If in doubt, budget more time for this phase.
• During this phase communication with Platform.sh onboarding team will be conducted via biweekly (every two weeks) meetings with ad hoc questions and assistance conducted via the Ticketing System.
• In the case of applications undergoing a longer development cycle prior to Go Live, the Customer must notify onboarding staff a minimum of 45 days prior to Go Live that the Provisioning and Go Live process should commence. This period ends when migration to Platform.sh development project is complete or development of a new application is ready for integration testing.

3.1.2.3. Provisioning and Go Live:

• This period will begin approximately 45 days prior to DNS cutover to Platform.sh. Customer must notify Platform.sh onboarding staff a minimum of 45 days prior to Go Live.
• During this time staging and production environments are provisioned and configured for Customer application(s). This is a collaborative process with lots of involvement from both Customer development staff and Platform.sh onboarding team.
• After hardware provisioning and configuration, CDN services are provisioned and configured (approximate 1 week prior to Go Live) After CDN is configured Platform.sh onboarding is largely complete and Customer may begin User Acceptance Testing.
• Go Live consists of final migration of data and content and cutting over of DNS.
• Customer must inform Platform.sh onboarding staff of the exact date and time of planned Go Live.
• Note: the onboarding service is provided during the customer business hours. Go Live should be planned accordingly on customer business hours.
• After Go Live, uptime monitoring and high SLA alerting is activated, so it is critical that Customer informs Platform.sh of the Go Live schedule.

3.12.4. Post Go live debriefing:

• Approximately 2 to 4 weeks after Go Live, a 30 minute review of the onboarding process will be scheduled with a Platform.sh Customer Success Manager and relevant staff from the development team.

3.2.Customer Success Manager (“CSM”)

3.2.1. Customer Success Managers partner with customers to ensure they are getting the most value possible from the platform. The CSM’s support the customer’s growth and provide a knowledgeable, responsive, and personable point of contact during their entire lifecycle. In conjunction with the Account Managers, they deliver quarterly business reviews (QBR) that include detailed information about Platform use, site health, best practices, and opportunities for early access to Platform features. The Customer Success Managers responsibilities include but are not limited to:

3.2.1.1 Ensures an exceptional experience for customers and partners by understanding their business objectives and helping to drive the adoption of core functionality

3.2.1.2. Establishes a trusted/strategic advisor relationship with customers by building a program vision and providing value throughout the customer partnership as they deliver on their program roadmap

3.2.1.3. Diagnose risks – takes action to solve or mitigate such risks.

3.2.2. Enterprise and Elite tier includes the CSM services listed below:

3.3.Technical Account  Manager (“TAM”)

3.3.1. Successful Platform.sh engagements are measured in years for our customers, and quite often the customer will have needs for larger and more strategic technical change management. The Platform.sh Technical Account Manager (TAM) team can assist with scoping and planning activities such as:

3.3.1.1 Major version upgrades of existing Platform.sh hosted projects. Any major version upgrade to underlying software frameworks such as Drupal, Magento, Wordpress, and so on bring with them an opportunity to ensure that the underlying hosting stack is as modern and optimized as possible.

3.3.1.2. Any technical change management for which Customer would like to consult with a technical member of the Platform.sh Customer Success team.

3.3.1.3.Should any of these scenarios present themselves, please reach out to the Customer Success Manager (CSM) to schedule a consultation with a technical team member.

3.3.2. Out-of-scope Activities:  TAMs are expert-level advisors and guides to Platform.sh products and services. TAMs are not development resources and thus certain activities are out of scope for TAM:

3.3.2.1 Write code, or modify existing code of any kind: including but not limited to any code in a website codebase, webpage authoring, shell scripts, or utility scripts.

3.3.2.2. Build or modify projects for Customer, including but not limited to website building, website administration or configuration, content authoring, editing, or administration.

3.3.2.3. Install, maintain, or configure software on Customer-maintained infrastructure.

3.3.2.4. Work on-site at a Customer’s business, outside of onsite visits described above.

3.3.2.5. Act as first responders for project emergencies. Customers should open a Urgent ticket with global Support as a first measure in an emergency.

3.4.Compliance assistance

3.4.1. Enterprise Tier  do not include Compliance Assistance, which must be subscribed to as a paid engagement.

3.4.2. Compliance Assistance is included in Elite Tier and includes, for instance.

3.4.2.1. Completing security questionnaires shared by Customer,

3.4.2.2. Making custom edits to the Platform.sh DPA or BAA,

3.4.2.3. Reviewing and signing Customer’s DPAs, BAAs,

3.4.2.4. Working directly with Customer’s auditors to assist in compliance audits,

3.4.2.5. Giving additional information about how Platform.sh shares the data; data flow, etc. (unless the information is already publicly available in Platform.sh’s  Privacy Policy or public documentation.)

4. Disaster Recovery & Business Continuity Plan

4.1. Platform.sh is responsible for establishing and maintaining an effective business continuity plan, including disaster recovery and crisis management procedures ( “Business Continuity Plan”). The Business Continuity Plan covers the hosting infrastructure of production environments that are under Platform.sh’s control, to the exclusion of all applications that are under Customer’s control and are built upon the Platform. For the avoidance of doubt, recovery as used in this section refers to the process of restoring infrastructure systems, data, and services to a functional and secure state following an incident. It specifically pertains to the restoration of the infrastructure managed by Platform.sh, as the Customer is responsible for their own applications and their recovery.

4.2.At a minimum, Platform.sh will:

4.2.1. back up, archive and maintain duplicate or redundant systems that can fully recover the Services and any data required to perform such Services on a daily basis;

4.2.2. establish and follow procedures and frequency intervals for transmitting backup data and systems to an alternate location; and

4.2.3. demonstrate that the Services, products, and/or support capabilities can be recovered within the agreed Recovery Point Objective (“RPO”) timeframe;

4.2.4.not less than annually following adoption of the Business Continuity Plan, conduct a test of the Business Continuity Plan.

4.3. Platform.sh will use reasonable efforts to restore the Services as follows:

4.3.1. The Recovery Time Objective (“RTO”) is subject to variability, contingent upon factors such as the size and complexity of the data being recovered, as well as the Customer's application configurations necessary for the complete recovery of the Customer Project.

4.3.2.The RPO is contingent upon the backups scheduled by both Platform.sh and the Customer, in accordance with the guidelines outlined in the Documentation accessible at https://docs.platform.sh/security/backups.html.