Gitlab hero border pattern left svg Gitlab hero border pattern right svg


GitLab offers a variety of support options for all customers and users on both paid and free tiers. You should be able to find help using the resources linked below, regardless of how you use GitLab. 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.

If you're using one of GitLab's free options, please refer to the appropriate section for free users of either self-managed GitLab or on

Note that free GitLab Ultimate and Gold accounts granted through trials or as part of a grant for educational institutions or open source projects do not come with support. Support for open source and education accounts can, however, be purchased at a significant discount by contacting Sales.

Contact Support

Plan Self-managed (hosted on your own site/server)
Core GitLab Community Forum
Starter Standard Support
Reply within 24 hours 24x5
Premium and Ultimate Priority Support
Tiered reply times based on definitions of support impact
Free GitLab Community Forum
Bronze Standard Support
Reply within 24 hours 24x5
Silver and Gold Priority Support
Tiered reply times based on definitions of support impact

Additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.

On This Page

GitLab Support Service Levels

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

Standard Support is included with all GitLab self-managed Starter, and Bronze plans while 'Next business day support' means you can expect a reply to your ticket within 24 hours 24x5.

Please submit your support request through the support web form. When you receive your license file, you will also receive an email address to use if you need to reach Support and the web form can't be accessed for any reason.

24x5 is defined as Sunday 3pm Pacific Time through Friday 5pm Pacific Time.

Priority Support

Priority Support is included with all self-hosted GitLab Premium and Ultimate licenses, as well as Gold and Silver plans. This includes:

Support Impact SLA Hours How to Submit
Emergency 30 minutes 24x7 When you receive your license file, you will also receive a set of email addresses to use to reach Support for emergency requests.

Note: In order to trigger an emergency page you must send a new email to the provided address. CCing the address on an existing thread will NOT page the on-call engineer.
Highly Degraded 4 hrs 24x5 Please submit requests through the support web form or via the regular support email.
Medium Impact 8 hrs 24x5 Please submit requests through the support web form or via the regular support email.
Low Impact 24 hrs 24x5 Please submit requests through the support web form or via the regular support email.

Definitions of Support Impact

Upgrading to Priority Support

Priority Support is automatically included on Silver and Gold plans as well as self-managed Premium and Ultimate plans. If your organization would like to upgrade to a plan with Priority Support, you can purchase it yourself online, email your account manager, or email

Service Level Agreement (SLA) details

Customer Satisfaction

24 hours after a ticket is Solved or automatically closed due to a lack of activity, a Customer Satisfaction survey will be sent out. We track responses to these surveys through Zendesk with a target of 95% customer satisfaction.

Support Management regularly reviews responses, and may contact customers who leave negative reviews for more context.

Phone Support

Inbound or on-demand calls are not currently a GitLab Support offering at any level. At times it may be necessary to escalate to a live troubleshooting session. While you may request to escalate to a live call, the supporting engineer will make the determination if (a) the call is necessary and (b) if sufficient information has been passed along to make the call successful.

As a result of a qualifying ticket, you will receive a link to schedule a call (or a direct link to a call in the case of Emergency support). Reuse of this link is considered abuse of support, and calls scheduled in this way will be cancelled.

Support for GitHost

Subscribers to GitHost receive next business day support via e-mail.

Please submit your support request through the support web form.

General Support Practices

Differences Between Support Tickets and GitLab Issues

It's useful to know the difference between a support ticket opened through our support portal vs. an issue on

For customers with a license or subscription that includes support, always feel free to contact support with your issue in the first instance via the support portal. This is the primary channel the support team uses to interact with customers and it is the only channel that is based on an SLA. Here, the GitLab support team will gather the necessary information and help debug the issue. In many cases, we can find a resolution without requiring input from the development team. However, sometimes debugging will uncover a bug in GitLab itself or that some new feature or enhancement is necessary for your use-case.

This is when we create an issue on - whenever input is needed from developers to investigate an issue further, to fix a bug, or to consider a feature request. In most cases, the support team can create these issues on your behalf and assign the correct labels. Sometimes we ask the customer to create these issues when they might have more knowledge of the issue or the ability to convey the requirements more clearly. Once the issue is created on it is up to the product managers and engineering managers to prioritize and drive the fix or feature to completion. The support team can only advocate on behalf of customers to reconsider a priority. Our involvement from this point on is more minimal.

We don't keep tickets open (even if the underlying issue isn't resolved)

Once an issue is handed off to the development team through an issue in a GitLab tracker, the support team will close out the support ticket as Solved even if the underlying issue is not resolved. This ensures that issues remain the single channel for communication: customers, developers and support staff can communicate through only one medium.

Issue Creation

Building on the above section, when bugs, regressions, or any application behaviors/actions not working as intended are reported or discovered during support interactions, the GitLab Support Team will create issues in GitLab project repositories on behalf of our customers.

For feature requests, both involving the addition of new features as well as the change of features currently working as intended, support will request that the customer create the issue on their own in the appropriate project repos.

Working Effectively in Support Tickets

As best you can, please help the support team by communicating the issue you're facing, or question you're asking, with as much detail as available to you. Whenever possible, include:

We expect for non-emergency tickets that GitLab administrators will take 20-30 minutes to formulate the support ticket with relevant information. A ticket without the above information will reduce the efficacy of support.

In subsequent replies, the support team may ask you follow-up questions. Please do your best read through the entirety of the reply and answer any such questions. If there are any additional troubleshooting steps, or requests for additional information please do your best to provide it.

The more information the team is equipped with in each reply will result in faster resolution. For example, if a support engineer has to ask for logs, it will result in more cycles. If a ticket comes in with everything required, multiple engineers will be able to analyze the problem and will have what is necessary to further escalate to developers if so required.

Closing Tickets

If a customer explains that they are satisfied their concern is being addressed properly in an issue created on their behalf, then the conversation should continue within the issue itself, and GitLab support will close the support ticket. Should a customer wish to reopen a support ticket, they can simply reply to it and it will automatically be reopened.

GitLab Instance Migration

If a customer requests assistance in migrating their existing self-hosted GitLab to a new instance, you can direct them to our Migrating between two self-hosted GitLab Instances documentation. Support will assist with any issues that arise from the GitLab migration. However, the setup and configuration of the new instance, outside of GitLab specific configuration, is considered out of scope and Support will not be able to assist with any resulting issues. Specific Support Policies

Account Recovery

If you have lost access to your account, perhaps due to having lost access to your 2FA device or the original email address that the account was set up with, the account may be recovered provided the claimant can provide sufficient evidence of account ownership. Use the support web form to request assistance.

Please note that in some cases reclaiming an account may be impossible. Read "How to keep your GitLab account safe" for advice on preventing this.

Dormant Namespace Requests

The Support Team will consider a namespace to be "dormant" when the user has not logged in or otherwise used the namespace for an extended time.

User namespaces can be reassigned if both of the following are true:

  1. The user's last sign in was at least two years ago.
  2. The user is not the sole owner of any active projects.

Group namespaces can be reassigned if one of the following is true:

  1. There is no data (no project or project(s) are empty).
  2. The owner's last sign in was at least two years ago.

If the namespace contains data, GitLab Support will attempt to contact the owner over a two week period before reassigning the namespaces. If the namespace contains no data (empty or no projects) and the owner is inactive, the dormant namespaces will be released immediately.

Namespaces associated with unconfirmed accounts over 90 days old will also be released immediately.

Namespace & Trademarks namespaces are available on a first come, first served basis and cannot be reserved. No brand, company, entity, or persons own the rights to any namespace on and may not claim them based on the trademark. Owning the brand "GreatCompany" does not mean owning the namespace "". Any dispute regarding namespaces and trademarks must be resolved by the parties involved. GitLab Support will never act as arbitrators or intermediaries in these disputes and will not take any action without the appropriate legal orders.

Further resources

Additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.