Welcome to the GitLab Support Handbook

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

On this page

Support Resources

Support Direction

The overall direction for Support in 2016 is set by our operations strategy, and in order to meet our strategic objective, the following topics are being addressed by the team: (also see the related direction issue)

Increase Capacity

By hiring more service engineers, adding Support Turbos when needed, and making sure that the newly hired service engineers have training materials and pathway readily available and defined when they join. We'll also aim to do a better job acknowledging and incentivizing the rest of the community in their role of supporting the community at large through contributions to documentation and participation in social channels.

Trend discovery

By gathering all our support channels in a central location, Zendesk, we'll be able to tag tickets with relevant keywords, and gather data on channel load, agent load, and topic trends. Likewise, through implementation of Swiftype on the documentation server, we'll get a better handle on what people are looking for and/or not finding.

Empower Users

By making training materials for customer trainings available on GitLab University, making documentation easy to find and easy to search, and constantly contributing to further documentation with the trend discovery showing where the need is greatest, we can help the community become as self sufficient as possible and empower users to problem-solve. A seamless interface between the support team and developers closes the feedback loop of user experience back to development, and provides 'network' support for the Service Engineers for tough issues.

Improve Customer Experience

By triaging support effort through internal SLAs, the team can improve the support experience for key customers while still addressing the questions of all subscribers, and the rest of the GitLab community.

Service and support we provide

For an overview of the support we provide to customers and users, please see the general support page. What follows is a more detailed description of the level of service.

Service Level Agreements

The channels are sorted in order of priority, there are 4 SLA categories:

SLA Channel Response Time
1 Emergencies 30 minutes
2 Regular Tickets and Security 1 business day
3 Disqus and Twitter 1 business day
4 Posted Issues & Other Two weeks but not sooner than two days

Response time indicates the first reply time.

Preferably we like to answer tickets sooner than the SLA requires. The higher a channel is in the list the sooner it should be answered.

The above SLAs are based on ticket priority which can be set manually by support agents. See setting ticket priority

Tiered Support

GitLab operates with three tiers of customer support. Each tier has a set of responsibilities as outlined below.

SLA Workflow

Service Engineers should work on tickets within their assigned support tier as a first priority. After these are addressed they can work on tickets in any tier. Tickets should be picked up in the following order to make sure that SLAs are not breached, and customers receive the proper level of service:

  1. Tickets that are close to breaching "first time to reply" SLA
  2. Tickets that are close to breaching "next time to reply" SLA
    • It is a courtesy to check with the assigned agent first, before "taking" one of these tickets. Ask if they can respond soon and offer to reply if they don't have the bandwidth.
  3. New tickets (not close to breaching)
  4. Other open tickets

When a ticket is breaching or has breached its first reply (or next reply) SLA this ticket must be picked up by any Service Engineer independently of who is assigned to it (although see the note re: courtesy in the list above). This also applies to tickets for Premium Customers (i.e. anyone picks up if close to breaching, regardless of who the Dedicated Service Engineer is).

Tier 1 Support

Examples of requests solved at Tier 1

Tier 2 Support

Tier 3 Support

Support requests escalated to tier 3:

Escalating between Tiers

We use 3 Zendesk macros to escalate between support tiers. These macros are located under the "Escalations" category in the ZD macros list.

Applying any of these macros will move the ticket to the tier group selected, create a quick internal note describing why you are escalating.

Zendesk SLA settings and Breach alerts

SLAs are set as Business Rules within Zendesk. For more information, please refer to the specific Zendesk page.

How we're doing

The Zendesk Insights dashboard lists the activity for all of our current channels and summarizes the last 30 days (Zendesk login required).

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.


"fix4all" is a rotation where one developer - or anyone in GitLab - spends a week of his or her time helping the support team, as described in more detail on the "fix4all" rotation page.

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. Support Turbos are separate from the "fix4all" rotation, in that Turbos are on an as-needed basis while the fix4all rotation is a week-long commitment per person. Anyone within the support team can call turbos when there is a need for it. Turbos can be called by pinging them on slack either individually or with @turbos.

The support team calls for help when necessary via Slack, but in case of doubt or conflicting priorities, the respective team lead or VP of Engineering needs to give the green light for the Support Turbo developers to momentarily switch away from their other tasks. As a general guideline for the Support Turbo, the order of priorities when called upon to join as a Turbo should be:

  1. Direction issues
  2. Turbo work
  3. P1 issues

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

Calls, Trainings, Implementation Support, and Live Upgrade Assistance

As described in more detail in the support listings as well as the support onboarding page, we offer services beyond simply responding to tickets. More information on scheduling customer calls can be found in the support standard operating procedures.

Implementation Support

We offer "implementation support" for new EE customers. This is similar to live upgrade assistance, except that live upgrade assistance is a Premium Support offering, while Implementation Support is an option available for purchase by any EE customer.

Requesting Implementation Support
What Implementation Support covers
What Implementation Support does not cover

Dedicated Service Engineers

We no longer offer Dedicated Service Engineers for Premium support, but we do offer them for Resellers where the relationship is deemed to be more important than the quick turnaround. This means that tickets that arrive in Zendesk from people within the reseller's organization are routed to a dedicated SE by way of a trigger in Zendesk.

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:
    • pose your question on the #questions channel in Slack, so that everyone can contribute to an answer. If you're not getting an answer, try pinging the group handle for the support team, but be aware that this pings everyone in the team.
    • or, email the internal support email alias that is listed in the "GitLab Email Forwarding" Google doc. Those emails create tickets in Zendesk.
  2. For longer term or larger scope questions, such as discussing customized training requests, create a support issue
  3. If customers or users have questions, advise them to contact support directly via the support web form.
  4. As a last resort, ping the support team on the support chat channel.

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 group. It should not contain any sensitive information. Links to Zendesk or other references are encouraged.

Support chat channels

We use our chat internally as a realtime communication tool. The support channels are as follows: