The purpose of this page is to direct GitLab team members outside of Support on what GitLab Support does, how to get in contact with us, and where to direct common requests that require our involvement. Are you a customer looking for technical support? If so, please visit the Support Page instead.
GitLab Support provides technical support GitLab.com and Self-Managed GitLab customers. We do not provide support for GitLab team members who are experiencing IT (1Password, Slack, Mac, etc.) issues. If you require assistance with issues of that nature, please contact Team Member Enablement.
For general questions regarding GitLab ("Can GitLab do x?", "How do I do y with GitLab?") please ask in #questions, or if you think you've encountered a bug or something isn't behaving right while using GitLab try asking in #is-this-known. Doing so ensures that everyone can contribute to an answer. If you're not getting one and believe that Support is the best team to ask, try cross-posting your question in the relevant GitLab Support channel.
However, keep in mind that those channels are specifically for questions about the various GitLab Support teams, not for questions about GitLab, the product. If you're working with a customer that requires technical support, please advise them to contact GitLab Support.
If you'd like to ask a longer term or larger scope question, propose an idea to GitLab Support, discuss something with us, or suggest an improvement or change to any of our workflows, please visit the issue tracker of the Support Team Meta project and create an issue there. Please keep in mind that it is open to the community and as such should not contain any sensitive information, so links to Zendesk or other references are encouraged.
The following channels are where GitLab Support can be found on Slack and are the best places to reach us, depending on what you need.
In order to attract GitLab Support's attention on Slack, you can use the team handles, mentioning multiple team members in a message or a thread where our urgent attention is needed. Support team handles are:
@support-selfmanaged- Self-managed support team members.
@support-dotcom- GitLab.com support team members.
@supportmanagers- Support director and managers.
If your customer contacts you requiring technical support, please immediately direct them to open a ticket through the Support Portal. It is Support's primary function to provide technical support for our customers and as paid users they are entitled access to us. If, for some reason they cannot access the Support Portal, please direct them to email
Please do not open a support ticket on behalf of a customer. Doing so will cause the ticket to not be tied to the customer's organization and the appropriate SLA that they are entitled to will not be applied to it.
According to our privacy policies, Support will not provide any information regarding customers, groups, projects, etc, to you that are not available publicly. This includes situations where a customer is requesting information about their own projects, groups, etc. If they are unable to authenticate, we cannot assume they are who they say they are. If they are locked out, please have them submit a support ticket.
All GitLab staff can request a 'Light Agent' account so that you can see customer tickets in Zendesk and leave notes for the Support team. These accounts are free.
To request a Light Agent Zendesk account, please send an email to
email@example.com - you'll receive an automated reply with the result of your request. You must send your request from your GitLab Google / Gmail account. No other addresses will work. The Subject and Body fields of the email can be empty. Once set up, you'll need to wait 24 hours for your account to be assigned Zendesk in Okta. Once Zendesk is assigned, you should be able to log in.
You cannot send public replies to customers with a Light Agent account - if you need to do this, please submit a new Access Request issue for a paid full agent account. If needed, you can read more information on Light Agent accounts from Zendesk.
|Request||What To Do|
|Schedule Upgrade Assistance Call||Open an issue using the
|Who is on-call for Self-Managed Support?||Run
|Who is on-call for GitLab.com CMOC?||Run
|Contact a GitLab.com User||Open an issue using the
|Excessive reCaptcha on GitLab.com||While it's happening, post in #support_gitlab-com and link to the issue/MR in question to be added to the allowlist.|
|Report complaints about support that you received from a client or prospect||Open an issue using the
|Request||What To Do|
|Claim Inactive GitLab.com Namespace||Open an issue using the
NOTE: Support will not start a trial. If one is needed, have the user initiate a normal trial first.
|Request||What To Do|
|Extend GitLab.com Trial||Open an issue using the
|Extend Self-Managed Trial||Open an issue using the
|Change GitLab.com Trial to Bronze or Silver||Open an issue using the
Grace period extensions are also treated similarly to trial extensions for self-managed. For GitLab.com, the customer should start a trial once their subscription has expired. To request these for either self-managed or GitLab.com, create a trial extension issue and update the title accordingly to indicate that it is an existing customer.
Please consider the following:
|Request||What To Do|
|Send/Resend EULA||Open an issue using the
|GitLab.com Billable Members List||Until #27074 or #35454 is implemented, open an issue using the
|Assistance With License Issue (not covered above)||Open an issue using the
|Assistance With a SaaS Subscription Issue (not covered above)||Open an issue using the
GitLab Support targets a 95% SLA acheievement KPI. This means that some tickets breaching is expected. Our SLA is for a First Reply but we also internally track next reply. Asking for eyes on or the escalation of a ticket in #support_gitlab-com or #support_self-managed creates unnecessary stress on Support Engineers who may be in the midst of working on higher priority tickets. Depending on whether you want to draw attention to either a Zendesk ticket or an issue created in
internal-requests, follow the steps below.
Review the SLA associated with the account and the amount of time left until a breach by logging into Zendesk using Okta. It's not typically necessary to escalate an issue that is hours away from a breach. If the ticket has had a first reply, then you are looking at an "internal breach".
#support_managers channel the Slack ticket escalation workflow can be initiated by following the steps below:
While on the
#support_managers, click on the small
lightning icon as shown in the image.
Complete the information requested on the form and click on
submit the workflow will be sent and automatically tag the support managers. You will also receive a private message with a confirmation.
All fields are required.
Understand that we'll do our best to prioritize appropriately taking into account all of the tickets in the queues - there may be more pressing items.
internal-requestshave no SLA.
If a ticket or issue escalation is posted in the wrong channel, simply add the
:escalation: emoji as a reaction to the post and the user will be directed to re-post the escalation in #support_managers via a Slack Workflow.
By default, trial licenses do not include support.
If you've been contacted by a prospect whose evaluation of GitLab includes evaluating support expertise or SLA performance, as a member of the Sales team you can grant temporary support for their trial license. You can do this from the organization's Salesforce record. Locate the field titled
Manual Support Upgrade and add a check mark. When you have done this, please wait 2 hours and then instruct your prospect to select
Sales assisted trial as their subscription level when submitting a support ticket.
Manual Support Upgradewill mean your prospect's tickets automatically get the correct SLAs.
Manual Support Upgradefield when your prospect no longer needs the service.
Manual Support Upgrades. This page will be updated when that work is completed.
The customer has more than likely run into an issue during the purchase process or is unaware of how to apply their subscription to their group. The following documentation outlines how to subscribe to GitLab.com, link your GitLab.com account to the Customers Portal, and apply that subscription to their group.
In some cases, certain organizations want all members of their organization to be able to see all of the support tickets that have been logged. In other cases, a particular user from the account would like to be able to see and respond to all tickets from their organization. If you'd like to enable this, please:
Shared Organization Requesttemplate. The issue will be used to review the request and track the history of changes.
To view the group's number of billable members, a member of the group with
Owner permissions may visit the Settings -> Billing section of it to see a breakdown. The number of billable members is the amount listed under
Seats currently in use and this is the amount that will come up whenever they link their group to a paid subscription. Billable members consist of every member who is added to a group, subgroup, or project within a paid namespace with the only exception being Guest users within a namespace on a Gold subscription.
Currently, there is no single API call or section of the UI that shows a full list of users. Customers can run the GitLab Group Leader tool, which will generate a report detailing where specific users have been added within their group(s) and any of its subgroups and projects. If the customer does not want to run this report themselves, they may submit a support ticket and we'll run it for them.