Platform.sh is responsible for infrastructure of the network and server(s) on which an application is running. Platform.sh is not responsible for application support for the code that you choose to run.
When filing an issue you believe to be infrastructure-related, please include as much information as possible to identify the issue as infrastructure-related and what a possible cause may be. That includes error messages, HTTP status codes, logs, screenshots, or other similar material. The more relevant information that is provided, the faster we can identify and correct an issue.
All Platform.sh users have access to our support ticketing system. Access is through the project admin UI of the Development Environment toward the top right under “Support”. To grant users access to the ticketing system simply add them to the Development project. Their level of access on that project does not matter; all users have access to the support ticketing system.
The primary language of our support team is English. We ask that you attempt to use English in the support queue so that the greatest number of our support engineers may assist in your support request, but language-specific needs can be negotiated during the sales process.
- Minor issue (P4). Issues which require attention, but do not significantly impact a production site or the use of non-production environments. Example: Deploys of development environments are taking an unusually long time.
- Normal issue (P3). Moderate- or low-impact issues affecting a production site or any issue affecting non-production environments. Example: Page requests are unusually slow, but the site is still serving all requests.
- Major issue (P2). Severe failures or high-impact issues affecting a production site although the site remains available. (Issues filed in this status will page a support engineer during normal business hours.) Example: Some page request are timing out, but not all or not consistently.
- Critical issue (P1). Total failure or unavailability of a production site. (Issues filed in this status will page a support engineer at any time of day). Example: The site is entirely offline.
Response times for P1 (critical) issues are guaranteed to be less than 1 hour. When a Critical/Urgent ticket is opened, the on call support and operations staff is immediately paged. While the response time is guaranteed to be within 1 hour, real world response times are often much quicker. Since on call staff is paged, please do not open Critical/Urgent support tickets for anything less than an outage or significant degradation of your production application.
Response times for P2 are guaranteed to be less than 1 business day.
Response times for P3 and P4 tickets are on a best effort basis, meaning as soon as possible but with the knowledge that other clients’ P1 tickets will receive priority.
In the project admin UI in your Development project, toward the top right there is a link/menu item “Support”. Under this menu item is an option to submit a new support ticket. Please follow this link to create a new ticket, and fill out all fields thoroughly in order to give the support team as much information as possible to aid them in resolving your issue.
It is important that your team follows the “submit ticket” link from the development project. This ensures that your ticket is populated with the correct project and Enterprise customer metadata and is triaged and prioritized correctly.
Direct, actionable ticket subject lines (“Stuck build on environment $foo in project $project_id”, “New PHP max_memory configuration for Enterprise cluster $shazbot”) are helpful in our ticket triage process. Vague ticket subjects such as “Problem” or “Questions” are inherently harder to process and inevitably lead to longer resolution times. When submitting a ticket, include as much information as possible to assist in diagnosing the issue (relevant URLs, error messages, configuration files, etc.). That helps avoid time consuming back-and-forth while we obtain enough information to resolve the issue.