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.
If it's not mentioned on this page, it's probably not Customer Support.
Please read the next sections on GitLab Support's Purpose and Should I Contact GitLab Support? section for more information.
| Problem | What to do |
|---|---|
| My customer can't open a ticket (or they get closed) | Make sure they are a support contact. Or maybe, they can't log into ZenDesk. |
| Customer is asking about a ticket | You probably want a Support Ticket Attention Requestion (STAR). If no ticket, open one |
| My customer has a subscription / license issue | If a ticket with the customer is not possible, open an internal request |
| I want to see tickets | Get a Light Agent ZenDesk account |
This is not an exhaustive list. For anything else you believe the Support team covers, please check the table of contents or search this page.
GitLab Support provides technical support for 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.
GitLab Support's Slack channels are specifically for 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.
If your customer contacts you requiring technical support, the following options are available to you:
(Recommended) In most cases, please 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 to access to us. This option is recommended as the customer is best positioned to describe their own issue and needs. Ensure that the customer understands that it will almost always be the fastest path to response to reach out to Support directly.
gitlab.com email addresses. Instead, use a private/incognito window in your browser to submit the ticket. When submitting the ticket, in the "Your email address" field, enter your customer's email address. If you should be CC'd on the ticket, please request it in the ticket body.For questions about specific customer situations, we need a support ticket (from the customer) or an internal request ticket (from a GitLab team member).
There are several reasons why Support cannot respond to customer-specific requests made through Slack:
If you want to request that we place additional attention on an existing ticket or internal request, please use the Support Ticket Attention Request Form (handbook entry).
GitLab.com users that have account or login issues should open a new ticket. They should select "GitLab.com (SaaS) User Accounts and Login Issues" as the reason for the request.
Customers having difficulty logging into the Zendesk customer portal should first try our documented troubleshooting steps. These steps almost always resolve the difficulty.
If those tips do not resolve the problem, you can open an Internal Request > Other on their behalf.
According to our privacy policies, Support does 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.
A Zendesk Light Agent account is required to view Support Tickets and can be obtained without manager approval.
To request a 'Light Agent' Zendesk account, please send an email to gitlablightagent.2lba7m@zapiermail.com. 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.
You'll receive an automated reply with the result of your request. Once set up, it takes between 2-24 hours for your account to be assigned to Zendesk in Okta. Once Zendesk is assigned, you should be able to log in. If your account is not assigned within 24h, please reach out to #support-operations in Slack. In most cases, people who don't receive access within 24 hours already had an end-user account, which prevents the automation from working as expected.
Note that 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 and tag your manager for budget approval. If needed, you can read more information on Light Agent accounts from Zendesk.
| Request | What To Do |
|---|---|
| Upgrade Assistance | Global organizations: Review the offering, then open a new ticket in the global support portal Public Sector organizations: Open a ticket in the U.S. Federal support portal |
| Who is on-call for Customer Emergencies? | Run /chatops run oncall support in a direct message to GitLab Chatops and review the results. This will not page the on-call engineer. |
| Who is on-call for GitLab.com CMOC? | Run /chatops run oncall cmoc in a direct message to GitLab Chatops and review the results. This will not page the on-call engineer. |
| 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 Indirect Feedback template. |
| See if an inactive GitLab.com Namespace can be claimed | Open an issue using the Name Squatting Request template. |
For GitLab team members, a GitLab license or plan request is done through Access requests. Please follow the appropriate handbook instructions, such as the Incentive instructions, or open an issue with the most appropriate template, such as the License request template for self-managed instances.
You can request Support to contact GitLab.com users on your behalf. Here are some cases when you can request us to contact users:
| Request | What To Do | Where to ask questions |
|---|---|---|
| Contact a user during an incident | Open a confidential infra issue, assign it to the current CMOC, use confidential_incident_data template |
#support_gitlab-com |
| Contact a single user | Open an issue using the Contact Request template |
#support_gitlab-com |
| Prepare Support for changes (with or without contacting select users) | Open a Support Readiness issue | #spt_managers |
| I need to reach out to many users | Review the tools and users table for a guide on how to most effectively send communications. | #spt_managers |
Please note: This is not for marketing or sales related contact. This channel is only for communication with users regarding important items that might affect their usage of GitLab SaaS.
All internal requests regarding licensing, subscriptions, trials, and grace period extensions should be filed using the GitLab Support Internal Request form. For internal requests, our SLO aligns with our SLA with customers for questions about licensing, which is that "GitLab Support will respond within 8 hours on business days (24x5)".
A list of common scenarios and the appropriate option are detailed in the following table.
- NOTE: Support cannot start a new trial. If one is needed, have the user initiate a normal trial first.
- NOTE: Support requires a single license or subscription request per ticket. If a provided license does not work, or you require a further extension, then please submit a new ticket. All internal L&R tickets must have a 1 to 1 relationship with the generated license or subscription, for audit/reporting reasons.
- NOTE: Please ensure that you selected the correct internal request form request prior to submission.
- NOTE: To speed up resolution, please fill in all form fields including SFDC link and additional context. Providing complete and accurate information, will enable L&R support to perform the steps needed to complete the request more efficiently.
| Option | Example Use Case |
|---|---|
| SaaS Subscription Related | |
| Extend an (almost) expired subscription | Use this when the customer has a subscription with us and their grace period is (almost) expired. Please note we cannot extend the actual subscription. This instead makes a trial for the namespace and uses that for the extension. |
| Investigate incorrect subscription info | Use this when the customer has a subscription with us and something is incorrect in their subscription information. This includes problems with: true-ups, subscription mismatches, can't apply subscription to group/namespace, and current seat usage counts. |
| Reset max seats for QSR | Use this after approval to waive the overage has been granted and documented via SFDC chatter. Once that is done, file the form to request that Support reset the max seats. |
| SaaS NFR license request | Ensure the group on GitLab.com has started a trial, then use this option to request a SaaS NFR subscription generation. |
| Billing Entity Change | Use this as part of the process of a billing entity change, to check whether the correct subscription is associated with the customer's group. |
| SaaS Trial Related | |
| Extend a SaaS trial | Use this when the customer's namespace is on a trial that is active/expired. Please note we cannot create the trial for the customer. If they do not have one currently, you will be directed to have them create one. |
| Change an existing SaaS trial plan | Use this when you want to make changes to the plan of a currently active trial, including adding CI minutes or activation of trial runners and overriding the requirement for credit card validation on sales assisted trial namespace. The number of users for GitLab.com trials are not restricted. Please note we cannot create the trial for the customer. If they do not have one currently, you will be directed to have them create one. |
| Self-Managed License Related (for paid customers only) | |
| Extend an (almost) expired subscription | Use this when the customer has a license and their grace period is (almost) expired. Please note we cannot extend the actual license. This instead makes a trial license for the customer and uses that for the extension. |
| Customer did not receive the license | Use this when the customer has not received a paid license from us when they should have. Please note we can resend a license to the contact in the license only. Please check for Proof of Delivery prior to filing this request |
| Customer needs the license resent to a new person | Use this to request sending a license to a different user. Please note we cannot send licenses to anyone other than the account owner. To send it to someone else, please ask the customer to file a ticket so we can go through the contact change process. An exemption can be made for a temporary license. |
| Multi-year license needs to be generated | Use this to request the next year's license for a multi-year subscription to be created. Make sure to check with the customer if they exceeded their seat usage before opening this request. Support cannot waive true-ups or change anything in SFDC. We cannot create a license until you have checked and amended their subscription as needed. |
| Self-managed NFR license request | Use this for Self-Managed NFR license generation |
| Cloud Licensing exemption | Use this for SCL exemptions |
| Self-Managed Trial Related | |
| Problems starting a new Self-managed trial | Use this when the customer has no recent trial or subscription, and is not able to request the trial themselves online. |
| Modify an existing Self-managed trial | Use this when you want to make changes to the number of users and/or the plan of a currently active trial |
| Extend an existing Self-managed trial | Use this when the customer is on a trial that is (almost) expired. |
| Other | |
| Order Management | Use this for Order Management requests. Please note if the license information you are requesting does not match the Salesforce opportunity, we will likely not be able to generate the license as Support cannot waive seats or Trueups. Ensure you include a summary of the action requested in the context field. |
| Hacker One Reporter License | Use this to request a license be generated for a Hacker One reporter. |
| Wider Community License | Use this to request a community license be generated. Please note for any license lasting longer more than 90 days, manager approval is required. Without an approving manager's email being provided, the ticket will be closed out |
| Other (nothing else fits the request) | Use this when nothing else fits. Please note if this is used when an option does exist, the request will be closed and you will need to re-submit your request using the correct option. |
Grace period extensions are treated similarly to trial extensions for both Self-managed and GitLab.com SaaS. To request these, file a request using the GitLab Support Internal Request form with the correct option as highlighted in the table above.
Please consider the following:
A copy of the license email sent to the customer is automatically logged under the Activity History of the Sold To Contact in SFDC when a subscription is created. Note that this will be a replica of the email the customer receives, but with the actual license key/activation code removed for compliance purposes. The subject line will begin with [GitLab Transactions].
Public Sector organizations: For confidential license issues relating to US Federal customers, GitLab team members can open a case with US Federal Support.
Open an Access Request using the GitLab_Team_Member_License_request template
As Product has implemented the minimal viable versions of #27074 and #35454, Support is beginning to deprecate this process. You can also see epic 4547 for improvements that product is working on and their progress.
Here are some options to get basic seat count information:
/chatops run namespace find group-pathIf none of the above self-serve options work, file a request using the GitLab Support Internal Request form
with the Other option providing the Group URL and any additional context.
Note: Support will only provide you with a screenshot of the billing page's subscription info. This includes:
Note: The public facing version of this information is on the Licensing and subscription FAQ page.
Customers can get their subscription information and a list of users using a seat on their group's Billing page (under the group Settings) or by using the Billable members API endpoint
To keep the term "escalation" MECEFU, Support uses the term "support ticket attention request" (STAR) to make sure account escalations are distinct. "Escalation" can also be confused with "emergency" or "incident."
Please open a support ticket attention request, during GitLab Global Support Hours only, if any of these are true:
More about support ticket attention requests
Please open an account escalation if:
More about account escalations
Please open an emergency ticket if:
More about how Support Engineers handle emergency tickets
Please declare a GitLab.com incident if:
More about GitLab.com incidents
Please declare a security incident if:
The Infrastructure team is the admin of GitLab.com, and any changes to product tuneables go through the change request workflow.
For information relating to priority prospects, please see Priority Prospects.
The customer has more than likely run into an issue during the purchase process, or is unaware how to apply their subscription to their group. The following documentation outlines how to subscribe to GitLab.com, link their GitLab.com account to CustomersDot, 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 requests in the Problem type field.Note: If a customer submits a shared organization request using a different Support form, simply change the form to Support Ops and select Shared organization requests in the Problem type field. Support Ops will then review the ticket and ask any followup questions if necessary.
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 user who is added to a group, subgroup, or project within a paid namespace with the only exception being Guest users within a namespace on certain subscription levels.
We have a billable members API endpoint that will produce a list of all the billable members for the group. This must be run with your own PAT.
All the billable members are also currently displayed on the group billing page in an unsorted list. This is a first iteration; if interested, you can view the epic to see the planned work. If you have any feedback on the billable members list or want to request functionality or UI changes that are not planned in the epic, please feel free to leave a comment on the epic.
Zendesk has the ability to store Organization and User notes. Using Zendesk triggers, we put these into each ticket submitted by that organization or user. If there is important information you wish to have included in tickets for an organization or user, please create an issue under the organizations project. template. Please be sure to indicate whether the information is only valid for a specific period of time so that we may include that fact in the notes.
Examples of some notes you might want added: