GitLab Support
There are many ways to contact Support, but the first step for most people should be to search our documentation.
Have questions about billing, purchasing, subscriptions or licenses?
We’re here to help! No matter what plan you have purchased, GitLab Support will respond within 8 hours on business days (24x5).
Open a Support Ticket on the GitLab Support Portal and select "Licensing and Renewals Problems".
Can’t find what you’re looking for?
If you can't find an answer to your question, or you are affected by an outage, then customers who are in a paid tier should start by consulting our statement of support while being mindful of what is outside of the scope of support. Please understand that any support that might be offered beyond the scope defined there is done at the discretion of the agent or engineer and is provided as a courtesy.
Managing your support contacts.
All individuals who will open support tickets must be associated with an organization that holds a valid GitLab subscription. If you are not pre-listed this will result in a rejection message detailing you how to manage your organizations support contacts. Please see our dedicated page on Managing Support Contacts for how to let GitLab Support know who is authorized to contact support.
Find your support level
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:
| Support Impact | First Response Time SLA | Hours | How to Submit |
|---|---|---|---|
| Emergency (Your GitLab instance is completely unusable) | 30 minutes | 24x7 | Please engage emergency support. |
| Highly Degraded (Important features unavailable or extremely slow; No acceptable workaround) | 4 hours | 24x5 | Please submit requests through the support web form. |
| Medium Impact | 8 hours | 24x5 | Please submit requests through the support web form. |
| Low Impact | 24 hours | 24x5 | Please submit requests through the support web form. |
Self-managed Premium and Ultimate may also receive:
- 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.
- 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:
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.
- GitLab offers 24x5 support (24x7 for Priority Support Emergency tickets) bound by the SLA times listed above.
- The SLA times listed are the time frames in which you can expect the first response.
- GitLab Support will make a best effort to resolve any issues to your satisfaction as quickly as possible. However, the SLA times are not to be considered as an expected time-to-resolution.
Definitions of GitLab Global Support Hours
- 24x5 - GitLab Support Engineers are actively responding to tickets Sunday 3pm Pacific Time through Friday 5pm Pacific Time.
- 24x7 - For Emergency Support there is an engineer on-call 24 hours a day, 7 days a week.
Effect on Support Hours if a preferred region for support is chosen
When submitting a new ticket, you are asked to select a 'Preferred Region for Support'. Please select the region that most closely aligns with your working hours. This helps us assign Support Engineers located in your preferred region.
For reference, the business hours for the various regions are as follows:
- Asia Pacific (APAC): 09:00 to 21:00 AEST (Brisbane), Monday to Friday
- Europe, Middle East, Africa (EMEA): 08:00 to 18:00 CET Amsterdam, Monday to Friday
- Americas (AMER): 05:00 to 17:00 PT (US & Canada), Monday to Friday
Phone and video call support
GitLab does not offer support via inbound or on-demand calls.
GitLab Support Engineers communicate with you about your tickets primarily through updates in the tickets themselves. At times it may be useful and important to conduct a call, video call, or screensharing session with you to improve the progress of a ticket. The support engineer may suggest a call for that reason. You may also request a call if you feel one is needed. Either way, the decision to conduct a call always rests with the support engineer, who will determine:
- whether a call is necessary; and
- whether we have sufficient information for a successful call.
Once the decision has been made to schedule a call, the support engineer will:
-
Send you a link (through the ticket) to our scheduling platform or, in the case of an emergency, a direct link to start the call.
-
Update you through the ticket with: (a) an agenda and purpose for the call, (b) a list of any actions that must be taken to prepare for the call, and (c) the maximum time allowed for the call. Please expect that the call will end as soon as the stated purpose has been achieved or the time limit has been reached, whichever occurs first.
During a screensharing session Support Engineers will act as a trusted advisor: providing troubleshooting steps and inviting you to run commands to help gather data or help resolve technical issues. At no time will a GitLab Support Engineer ask to take control of your computer or to be granted direct access to your GitLab installation.
Note: Calls scheduled by GitLab Support are on the Zoom platform. If you cannot use Zoom, you can request a Cisco Webex link. If neither of these work for you, GitLab Support can join a call on the following platforms: Microsoft Teams, Google Hangouts, Zoom, Cisco Webex. Other video platforms are not supported.
Please Note: Attempts to reuse a previously-provided scheduling link to arrange an on-demand call will be considered an abuse of support, and will result in such calls being cancelled.
Resources
Additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.
Or check our some of our other support pages: