Support Handbook

Welcome to the GitLab Support Handbook

Looking for technical support? Please visit the Support Page instead.


On this page


What does the Support Team do?

GitLab Support provides technical support to our Self-managed and GitLab.com customers for the GitLab product.

We aren't internal IT Support, so we probably can't help you with your MacBook or 1Password. (Check in with #peopleops for who to go to for these problems!)

If you're looking for some help as a team member, please see the internal support for GitLab team members section.

If you're a customer (or advocating for a customer), you should take a look at the dedicated Support Page that describes how to get in contact with us.

Support Direction

The overall direction for Support in 2018 is set by our overall strategic objectives, with a particular emphasis on continued improvement of (Premium) Customer satisfaction. As can also be inferred from our publicly visible OKR page, the effort focuses on the following elements.

Triaging Support Effort

By triaging support effort through internal SLAs and integration of SalesForce, Zuora, and Zendesk, the team can improve the support experience for Premium customers while still addressing the questions of all subscribers.

Increase Capacity & Develop Experts

In 2016 and 2017 we expanded the support team significantly, and this trend will continue in 2018. Along the way, the Support team developed internal training tools to assist in rapid, robust, self-guided training for any team member. As GitLab – the product – continues to expand, so will the skill and knowledge of all Support Engineers to be able to continue providing an excellent customer support experience.

Know someone who might be a great fit for our team? Please refer them to the

Actionable Analytics

Better reporting on ticket metrics (topic, response times, product it relates to, etc.) will help guide the Support Team's priorities in terms of adding to the greatest documentation needs, bug fixes, and support processes.


What if I Feel Threatened or Harassed While Handling a Support Request?

Just as Support Team are expected to adhere to the Code of Conduct, we also expect customers to treat the Support Team with the same level of respect.

If you receive threatening or hostile emails from a user, please create a confidential issue in the GitLab Support Issue Tracker and include:

  1. A history of the user's communication
  2. Relevant links
  3. Summary of the high-level issues
  4. Any other supporting information

Include your Manager, Director of Support, Abuse Team and Chief Culture Officer in this issue. Together we will evaluate on a case-by-case basis whether to take action (e.g. ban the user from the forums for violating the Code of Conduct).

Our Meetings

Support has several meetings each week. These allow us to coordinate and help us all grow together. Each meeting has its own agenda and is led by a different member of the team each week.

Weekday Region Meeting Name Purpose
Tuesday APAC Support Call Discuss metrics, demos, upcoming events, and ask questions
Tuesday AMER Ticket Crush Session Perform demos and cooperatively solve challenging tickets as a group
Wednesday AMER,EMEA Dotcom Support Call GitLab.com support team meeting to discuss metrics, demos, upcoming events, and ask questions
Thursday EMEA Support Call Discuss metrics, demos, upcoming events, and ask questions
Friday AMER,EMEA Support Call Discuss metrics, demos, upcoming events, and ask questions

The regions listed above are the regions for which each call may be the most convenient, but all are welcome on any call. Every call is recorded and notes are taken on the agenda for each one. If you miss a meeting or otherwise can't make it, you can always get caught up.

All Zoom and agenda links can be found on the relevant calendar entry in the Support Calendar.

Role of the Notetaker

The notetaker should take notes during the meeting and if action is required, creates a comment and assigns it to the appropriate person.

If the notetaker is not available when it is their turn, they should find a substitute.

Role of the Chair

The main role of the chair is to start the meeting, keep the meeting moving along, and end the meeting when appropriate. There is generally little preparation required, but depending on the meeting, will include choosing a "feature of the week" or similar. Please check the agenda template for parts marked as "filled in by chair."

During the meeting, the chair:

If a chair is not available, it is their responsibility to find a substitute.

Improving our processes - team meeting issue reviews

The Support team use 'support-team-meta' project issues to track ideas and initiatives to improve our processes. The 'Active Now' issue board shows what we're currently working on. It uses three labels:

  1. Blocked - waiting for another team or external resource before we can move ahead
  2. Requesting comments - under active discussion to arrive at a decision
  3. In Progress - actively being worked on

Some principles guide how these labels are used:

  1. A maximum of six issues at any time for each label (18 total issues)
  2. All issues with one of the above labels must be assigned to one or more support team members
  3. All issues with one of the above labels must have a due date no longer than a week ahead
  4. If an issue is too big to complete in a week it should be split into smaller parts that can be completed in a week (a larger 'parent' issue is OK to keep in the project, but it shouldn't make it onto the 'In Progress' column)

At every team meeting we look at the board and discuss the issues to keep things moving forward.

By keeping a maximum of six issues for each label, we limit work in progress and make sure things are completed before starting new tasks.

The team can vote on issues not on the board by giving a 'thumbs up' emoji so we can see popular issues. In team meetings we can look at these and add them to the board when there is room.

Support managers will curate issues to prevent a large backlog. Unpopular or old issues can be closed / merged to keep the backlog manageable.

Weekly Metrics in Brief

The links to the relevant ZenDesk views are in the agenda template, but can also be found under the Reporting tab in ZenDesk. Two areas to cover:

  1. Satisfaction tab: Meeting our CSAT OKR?
  2. Insights > Support SLAs: Meeting our SLA OKR?

Answers to questions, deeper insight, and analysis is not expected of the chair. Support Managers will cover metrics in more depth as needed.

If you're presenting metrics for the first time and want to see how it is done, please see past recordings of our meetings.

Cross Functional Meetings

As a result of our direct interactions with customers, the Support Team occupies a unique position in GitLab. As such we have standing meetings across functions to help surface issues and smooth the interface between groups. If you're missing from this list (and want to be on it) please let the Support Managers know in #support-managers

If you're on the Support Team and have something you'd like to surface, or would like to attend one of these meetings, feel free to post in #support-managers.

Function Party Support Rep Frequency
Production Dave Smith Lyle Kozloff every 2 weeks
Product Jeremy Watson Lyle Kozloff every 2 weeks
UX Taurie Davis Lyle Kozloff every 1 week
PeopleOps Jessica Mitchell Lee Matos every 2 weeks
Finance Chase Wright Tom Cooney 1x Qtr on budget + once per month
PeopleOps Jessica Mitchell Tom Cooney every 2 weeks
Recruiting Nadia Vatalidis Tom Cooney weekly
Docs Docs Team Tom Atkins every 2 weeks join docs meeting
Sales + CS EMEA Sales/CS Tom Atkins weekly on Fri join EMEA scrum

Time Off

The Support Team follows GitLab's paid time off policy. However, do note that if a large number of people are taking the same days off, you may be asked to reschedule. If a holiday is important to you, please schedule it early.

In addition to the tips in Communicating Your Time Off please also:

If you do not have access to the Support Time-off team calendar, please raise it in the #support-team-chat channel on Slack and someone will share it with you.

You do not need to add time-off events to the shared calendar if you'll be gone less than half a day. Do consider blocking off your own calendar so that customer calls or other meetings won't be scheduled during your time away.

If you need to go for a run, grab a coffee or take a brain break please do so without hesitation.

Support Ops

Please see Support Ops.

Additional Resources for the Support Team

Breach Hawks

Breach hawks are members of the support team who help the rest of the team keep an eye out for nearly-breaching tickets, so that they can be responded to in a timely manner. Of course, any and all members of the Support Team will have a sense of how many tickets are close to breaching and how high the load is on any given day. But it can happen that you're deep into a ticket, a customer call, etc., unaware of the impending doom. That's where breach hawks come in: they tackle their tickets, but they also keep an eye out for the team at large and can call in the Support Turbos when needed.

Support Turbo

Every now and then, it may occur that we come close to breaching our SLAs. To prevent an actual breach from occurring, the Support team can call on the help of several "Support Turbo" developers who are denoted on the Team Page.

Anyone within the support team can call Turbos when there is a need for it. Turbos should be called by pinging specific people via Slack. If you are in doubt who is available, you can use @turbos, but this may lead to a bystander effect.

The support team calls for help when necessary via Slack. Support Turbos should treat requests to solve breaching tickets with high priority. If a Turbo is working on something that cannot wait (e.g. security release, critical regressions, direction issues with near deadlines), the Turbo should ensure that someone else fields the request for Turbos by checking with the development lead or VP of Engineering.

Further guidelines when rolling up your sleeves to do Turbo work:

Contacting Support

Internal Support for GitLab team members

Fellow GitLab team members can reach out for help from the Support Team in various ways:

  1. For normal support questions ("Can GitLab do x?", "How do I do y with GitLab?") try:
    • posing your question on the #questions channel in Slack, so that everyone can contribute to an answer. If you're not getting an answer, try cross-posting in the relevant support team channel.
  2. For longer term or larger scope questions, such as process change, or data gathering requests, create a support issue
  3. If you have a user or account request that needs a GitLab.com administrator, please create an issue in the dotcom internal requests tracker.
  4. If customers or users have questions, advise them to contact support directly via the support web form.
  5. As a last resort, ping the support team on one of the support channels.

Support Issue Tracker

The Support project hosts an issue tracker meant to improve our workflow by reporting any problems that may arise in our tools or processes. It's also meant to propose and discuss ideas in general.

The issue tracker is open to the community and part of the GitLab.com group. It should not contain any sensitive information. Links to Zendesk or other references are encouraged.

Support Chat Channels

The support channels are as follows:

In order to attract support team's attention in Slack, you can use the team handles, mentioning multiple team members in a message or a thread where support is needed. Support team handles are:

Support Resources