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 SLA's, 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 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.

SLA Workflow

Service Engineers can work on any ticket they feel they can contribute to. However, tickets should be picked up in the following order to make sure that SLA's 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).

Support Turbo

Every now and then, it may occur that we come close to breaching our SLA's. To prevent an actual breach from occurring, the Support team can call on the help of several 'Support Turbo' developers who are called out on the Team Page. The support team calls for help when necessary via Slack, but in case of doubt or conflicting priorities, the Backend Lead needs to give the green light for the support turbo developers to momentarily switch away from their other tasks.

Zendesk SLA settings and Breach alerts

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

Zendesk Dashboard

The Zendesk Insight dashboard lists the activity for all our channels currently and summarized over the last 30 days (login to Zendesk required).

We can't fit more than 13 views in the dashboard panel. We have 6 views that are not channels. Meaning we have 7 views left for all our channels. That is why some channels are combined.

Dedicated Service Engineers

Certain subscribers have purchased Premium Support (TODO: create /support page), which gives them access to a Dedicated Service Engineer. This means that tickets that arrive in Zendesk from people within the subscriber's organization are routed to a dedicated SE by way of a trigger in Zendesk.

Security disclosures

We have a Responsible Disclosure Policy. Emails sent to go into Zendesk and receive an autoresponder that says: "Thank you for your responsible disclosure of a potential GitLab vulnerability. We'll follow up with you within one business day." We also accept reports via HackerOne, see more information on this channel.

Please be very patient with these reports. Do not say 'there is no problem', you might be misunderstanding something that can lead to a 0 day disclosure. Give examples and keep asking questions until you understand the problem or until the researcher concludes there is no problem. If someone invested time to help us, offer to mention them on our Security Researcher Acknowledgments page even if there was no actual vulnerability. If you say that we'll get back to them always mention that they can email us at any time for an update. This is really important to prevent a 0 day disclosure resulting from us forgetting to respond.

If you need help from developers to diagnose the issue please open an issue on so we can work in private. If someone opens a public issue please leave a message: "Thank you for helping to make GitLab more secure! We removed the contents of your vulnerability disclosure to keep it private. We opened an internal issue to look at your disclosure. Can you please use our Responsible Disclosure Policy to send us an email that references this url so we can communicate in private?"

PGP Process

The key used to encode/decode PGP messages is stored in our Support Vault on 1Password. We only provide our public PGP key upon request because it makes collaborating much harder and only a small percentage of all disclosures are serious enough to require that overhead.

See PGP Process for information about using the security PGP key pair and decrypting messages.

Internal Support

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 x with GitLab) 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 direct via the relevant channel.
  4. For quick questions that are urgent ping the support team on the support chat channel.

Contacting support

Support Issue Tracker

The Support project hosts an issue tracker meant to improve our workflow by reporting any problems that may arise on our tools or processes. Its 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 communication tool. The support channels are as follows: