Issue Escalations

On this page

Escalating GitLab issues correctly is an important part of providing quick and accurate customer support. The support team uses the processes and escalation points described on this page when dealing with GitLab issues.

Issue Prioritization

In general, the Product team will prioritize all issues (not just customer requests) as described elsewhere in the handbook, specifically for the product managers, and for engineering. From those pages, generally, it goes in order of:

  1. Regressions
  2. Bugs
  3. Product Direction / Vision
  4. New Feature Proposal

The Support Team plays a role in communicating the impact to customers of regressions, bugs, and feature requests. By using issue templates and then using the appropriate labels on those issues, the team can communicate within the support team about which customer-affecting issues are high priority, and also show this to the team at large. By then participating in the scheduling effort for each release, the Support Team represents the voice of the customer in product development.

Make important issues visible to the Product team

The best way to get attention by the Product team is to know how Product chooses issues to prioritize and to ship in the next release. These are the criteria that allow a good communication about priorities between the Support team and the Product team:

  1. Consider labeling an issue as ~SP1 only if:
    • It is a relevant ~bug
    • You really think this is something that should be done in the next release
    • The issue is critical for the relationship with a customer (use also ~customer or ~"customer+" labels in this case)
  2. Label the issue with the proper team label, this is the first label PMs filter for when they want to schedule issues
  3. Label the issue as ~regression, ~bug, ~"feature proposal" or ~"enhancement"

If the PM will find only a few issues marked as ~SP1 while planning, it is easier they can be included in the scheduling. Having a lot of results can make it difficult to figure out what should be done to help the Support team.

When contributing to the issue, it is valuable to add the most detailed description possible (removing sensitive details in case), it is easy to figure out the scenario without jumping into the Zendesk ticket. Providing a link to the ticket is a good practice, anyway.

The Support team can directly ping the PM in the #product Slack channel (see who to talk to) in case this may help the communication.

When writing in issues, be specific: do not simply cc as this does not indicate what action is required. For example: "@PM please provide feedback on this issue. Are we interested in fixing/implementing this? How critical do you think it is?"

General notes on making issues

Use templates

When reporting a bug/regression or feature proposal. For example, gitlab-ce project has 'Bug' and 'Feature Proposal' templates.

Use labels

Always. Use either ~bug or ~feature proposal and also add ~customer. For certain premium subscribers, you may need to use ~customer+. If there are one or more component labels that are appropriate, such as ~ldap, add those, too. Add Support Priority labels ( ~SP1, ~SP2, ~SP3) to indicate perceived priority inside the Support Team.

Maintain confidentiality

If an image, log output, etc. is required for the issue, try to produce your own test image. If you are unable to reproduce the issue and you wish to use the image provided by the customer make sure you obtain permission from the customer since the image may (inadvertently) include sensitive information like names, group names, user names, or code.

Information gathering

For the Application and environment information section of issue templates, use:


We aim to fix regressions in patch releases, when possible. However, not all regressions are created equal - we will work to patch the high-impact ones first.

For all regressions, add the ~regression label and the milestone the regression was introduced in. For high-impact regressions, also add ~"Next Patch Release" and ping the relevant lead, along with any experts on the subject area.

Bugs and Feature Proposals

By default, add an appropriate support priority label to bugs and feature proposals. The labels are ~SP1, ~SP2, and ~SP3, where SP1 is the highest priority. These labels are applied in addition to the ~bug, ~feature proposal and ~customer labels. Use priority labels in accordance with the urgency / impact matrix below.

The reasoning behind adding an ~SP label to every of these issues is that each issue should have had someone consider the urgency and impact, and this is best done at time of creating the issue since that is when the information and context is "fresh" in your memory. It is OK to change the assessment and label at a later date upon reflection (for example, during the support-internal scheduling meeting). When an issues are allowed to be filed without an ~SP label it will be unclear whether an issue lacks the label due to lack of urgency / impact, or due to missing a step in the process.

Note about feature proposals: GitLab has limited development resources. Additionally, we must think about how widely applicable a feature may be to other users. Requests that are very specific to one company's workflow are likely to be rejected. Even if a feature seems widely applicable, we may leave the feature proposal dormant for some time and see if other users and customers chime in that they are also interested. Features that garner interest from multiple organizations will be considered more rapidly. Of course, there are always exceptions to these 'rules'. This note is meant to set the expectation that feature proposals may not be implemented quickly.

For feature proposals, please also use the feedback template provided by the product team to provide more context whenever possible.

Support Priority labels

Use the following as a guideline to determine which Support Priority label to use (if any) for bugs and feature proposals.

Urgency \ Impact I1 - High I2 - Medium I3 - Low
U1 - High SP1 SP1 SP2
U2 - Medium SP1 SP2 SP3
U3 - Low SP2 SP3 SP3

Escalating from the Support Team to the Development Team

On the last Tuesday of each month, the Support Team reviews the SP labeled issues (especially SP1 and SP2), discusses priorities, and chooses the top few to present to the Product team for potential deliverables in the next release.

After the support team prioritizes it, we ping the relevant product manager for the express purpose of scheduling. Having the Product team comment in the issues directly follows our core value of being transparent and will help customers understand the context around why / when their issues are being resolved, and it provides direct feedback from customers to the Development and Product teams.

Working this way, it is possible that a customer reported issue is not picked up for a while (scheduling first, then time to work on a fix, then schedule for release, etc.). However, the idea is that this is OK because most truly urgent issues will in fact be regressions that don’t have this scheduling problem. If a bug isn't a regression, that means it has existed for more than a month when the customer notes it, and thus we've gone at least a full month without someone reporting the issue as urgent.


Functional escalation points

Service/Product Escalation Types Escalation Point Assignment
GitLab CE Bug reports, Feature proposals  
GitLab EE Bug reports, Feature proposals Bug reports, Feature proposals Maintainer of
Omnibus GitLab Bug reports, Feature proposals Omnibus GitLab specialist
GitLab Runner Bug reports, Feature proposals GitLab CI specialist
GitLab Workhorse Bug reports, Feature proposals Maintainer of gitlab-workhorse

See the GitLab team page for assignments

Operational escalation points

Service/Product Escalation Type Escalation Point Assignment
GitLab Infrastructure Anything related to the running of, performance, something breaks Production Lead/Senior Production Engineer Support Engineers Anything related to the use of, operations that can't be performed with admin access Use ~"SE Escalation" label
GitLab Support Any and all questions in relation to providing customer service for GitLab users and customers. Support Team Lead/Senior Support Engineer

See the GitLab team page for assignments


Omnibus GitLab

GitLab Runner

GitLab Workhorse

GitLab Infrastructure