There are many ways to contact Support, but the first step for most people should be to search our documentation.
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.
Find your support level
Depending on how you purchased, upon the creation of your first ticket GitLab Support may not be able to automatically detect your support entitlement. If that's the case, you will be asked to provide evidence that you have an active license or subscription. A variety of types of proof are accepted.
If you want to make sure contacts in your organization aren't required to submit this proof, please see our dedicated page on Managing Support Contacts for how to get set up with a named set of contacts.
Standard Support is included in Legacy GitLab self-managed Starter, and GitLab.com Bronze plans. 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 is included with all self-managed and SaaS GitLab 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 trigger an emergency|
|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.
To trigger emergency support you must send a new email to the emergency contact address provided with your GitLab license. When your license file was sent to your licensee email address, GitLab also sent a set of addresses to reach Support for emergency requests. You can also ask your Technical Account Manager or sales rep for these addresses.
- Note: CCing the address on an existing ticket or forwarding it will not page the on-call engineer.
It is preferable to include any relevant screenshots/logs in the initial email. 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.
- 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
- 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 usuable 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.
When submitting a new ticket, you may select a 'Preferred Region for Support'. This can help us assign Support Engineers from your region and can make the ticket more likely to receive replies in the specific region's business hours (rather than at night).
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
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.
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:
For additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.Visit Get Help page