Support (original) (raw)

Trials Support

Trial licenses do not include support at any level. If part of your evaluation of GitLab includes evaluating support expertise or SLA performance, please consider contacting Sales to discuss options.

Standard Support (Legacy)

Standard Support is included in Legacy GitLab self-managed Starter. It includes 'Next business day support' which means you can expect a reply to your ticket within 24 hours 24x5. (See Support Staffing Hours).

Priority Support

Priority Support is included with all self-managed and GitLab.com Premium and Ultimate purchases. These plans receive Tiered Support response times:

Self-managed Premium and Ultimate may also receive:

1. Support for Scaled Architecture: A Support Engineer will work with your technical team around any issues encountered after an implementation of a scaled architecture is completed in cooperation with our Customer Success team.
2. Upgrade assistance: A Support Engineer will review and provide feedback on your upgrade plan to help ensure there aren't any surprises. Learn how to schedule an upgrade.

How to engage Emergency Support

To engage emergency support you should use the form for the support instance you are working out of:

• Global Support
• US Government Support

It is preferable to include any relevant screenshots/logs in the initial ticket submission. However if you already have an open ticket that has since evolved into an emergency, please include the relevant ticket number in the initial email.

• Note: For GitLab.com customers our infrastructure team is on-call 24/7 - please check status.gitlab.com before contacting Support.

Once an emergency has been resolved, GitLab Support will close the emergency ticket. If a follow up is required post emergency, GitLab Support will either continue the conversation via a new regular ticket created on the customer's behalf, or via an existing related ticket. Support Emergencies are defined as "GitLab instance in production is unavailable or completely unusable". The following is non-exhaustive list of situations that are generally considered as emergencies based on that definition, and a list of high priority situations that generally do not qualify as an emergencies according to that definition.

Emergency:

• GitLab instance is "down", unavailable, or completely unresponsive (for GitLab.com outages, an Incident will be declared)
• GitLab always shows 4xx or 5xx errors on every page
• All users in an organization are unable to login to GitLab
• All users in an organization are unable to access their work on GitLab

Non-emergency:

• A single user is unable to login to GitLab.
• GitLab Runner or CI job execution is slower than usual.
• A CI pipeline is failing on one or more projects but not all projects.
• One or more pages are not responding in browser, but most pages load successfully.
• An access token has stopped working or SSH key has expired.
• License/Subscription about to expire (there is a 14-day grace period following license expiration).
• GitLab application is usable but running slower than usual.
• Security incident affecting a publicly-accessible and unpatched self-managed GitLab server.
• A Geo secondary is unhealthy or down.
• Elasticsearch integration is not working.

To help Support accurately gauge the severity and urgency of the problem, please provide as many details about how the issue is impacting or disrupting normal business operation when submitting the emergency ticket.

The SLA times listed are the time frames in which you can expect the first response.

Definitions of Support Impact

Severity 4 | Low

Questions or Clarifications around features or documentation or deployments (24 hours) Minimal or no Business Impact. Information, an enhancement, or documentation clarification is requested, but there is no impact on the operation of GitLab. Implementation or production use of GitLab is continuing and work is not impeded. Example: A question about enabling ElasticSearch.

Severity 3 | Normal

Something is preventing normal GitLab operation (8 hours) Some Business Impact. Important GitLab features are unavailable or somewhat slowed, but a workaround is available. GitLab use has a minor loss of operational functionality, regardless of the environment or usage. Example: A known bug impacts the use of GitLab, but a workaround is successfully being used as a temporary solution.

Severity 2 | High

GitLab is Highly Degraded (4 hours) Significant Business Impact. Important GitLab features are unavailable or extremely slowed, with no acceptable workaround. Implementation or production use of GitLab is continuing; however, there is a serious impact on productivity. Example: CI Builds are erroring and not completing successfully, and the software release process is significantly affected.

Severity 1 | Urgent

Your instance of GitLab is unavailable or completely unusable (30 Minutes) A GitLab server or cluster in production is not available, or is otherwise unusable. An emergency ticket can be filed and our On-Call Support Engineer will respond within 30 minutes. Example: GitLab showing 502 errors for all users.

Ticket severity and customer priority

When submitting a ticket to support, you will be asked to select both a severity and a priority. The severity will display definitions aligning with the above section. Priority is lacking any definition - this is because the priority is whatever you and your organization define it as. The customer priority (shorted on the forms as priority) is Support's way of asking the impact or importance the ticket has to your organization and its needs (business, technical, etc.).

Note: The US Government support portal is often setup differently than the Global support portal and might differ in the questions asked via the ticket submission forms.