ContextQMD
Back to Gitlabhq

Labels

doc/user/project/labels.md

18.11.224.0 KB
Original Source

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Labels organize and track work across GitLab features. As projects grow from small teams to large organizations, labels help you track and manage increasing volumes of work. Labels:

  • Categorize issues, merge requests, and epics with custom attributes.
  • Filter content in lists and boards.
  • Prioritize work items with colors and descriptive titles.
  • Track priority and severity with scoped labels.
  • Structure workflows through organized groupings.

Types of labels

Use three types of labels in GitLab:

  • Project labels can be assigned to issues and merge requests in that project only.
  • Group labels can be assigned to issues, merge requests, and epics in any project in the selected group or its subgroups.
  • Instance labels are created by instance administrators and are copied to all new projects.

Assign and unassign labels

{{< history >}}

{{< /history >}}

You can assign labels to any issue, merge request, or epic.

Changed labels are immediately visible to other users, without refreshing the page, on the following:

  • Epics
  • Incidents
  • Issues
  • Merge requests

To assign or unassign a label:

  1. In the Labels section of the sidebar, select Edit.
  2. In the Assign labels list, search for labels by typing their names. You can search repeatedly to add more labels. The selected labels are marked with a checkmark.
  3. Select the labels you want to assign or unassign.
  4. To apply your changes to labels, select X next to Assign labels or select any area outside the label section.

Alternatively, to unassign a label, select the X on the label you want to unassign.

You can also assign and unassign labels with quick actions:

  • Assign labels with /label.
  • Remove labels with /unlabel.
  • Remove all labels and assign new ones with /relabel.

View available labels

View project labels

To view the project's labels:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.

Or:

  1. View an issue or merge request.
  2. In the right sidebar, in the Labels section, select Edit.
  3. Select Manage project labels.

The list of labels includes both the labels created in the project and all labels created in the project's ancestor groups. For each label, you can see the project or group path where it was created.

View group labels

To view the group's labels:

  1. In the top bar, select Search or go to and find your group.
  2. Select Manage > Labels.

Or:

  1. View an epic.
  2. In the right sidebar, in the Labels section, select Edit.
  3. Select Manage group labels.

The list includes all labels created only in the group. It does not list any labels created in the group's projects.

Create a label

{{< history >}}

  • Minimum role to create a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project or group.

Create a project label

To create a project label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Select New label.
  4. In the Title field, enter a short, descriptive name for the label. You can also use this field to create scoped, mutually exclusive labels.
  5. Optional. In the Description field, enter additional information about how and when to use this label.
  6. Optional. Select a color by selecting from the available colors, or enter a hex color value for a specific color in the Background color field.
  7. Select Create label.

Create a project label from an issue or merge request

{{< history >}}

  • Minimum role to create a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

You can also create a new project label from an issue or merge request. Labels you create this way belong to the same project as the issue or merge request.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.

To do so:

  1. View an issue or merge request.
  2. In the right sidebar, in the Labels section, select Edit.
  3. Select Create project label.
  4. Fill in the name field. You can't specify a description if creating a label this way. You can add a description later by editing the label.
  5. Select a color by selecting from the available colors, or enter a hex color value for a specific color.
  6. Select Create. Your label is created and selected.

Create a group label

To create a group label:

  1. In the top bar, select Search or go to and find your group.
  2. Select Manage > Labels.
  3. Select New label.
  4. In the Title field, enter a short, descriptive name for the label. You can also use this field to create scoped, mutually exclusive labels.
  5. Optional. In the Description field, enter additional information about how and when to use this label.
  6. Optional. Select a color by selecting from the available colors, or enter a hex color value for a specific color in the Background color field.
  7. Select Create label.

Create a group label from an epic

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

  • Minimum role to create a group label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

You can also create a new group label from an epic. Labels you create this way belong to the same group as the epic.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the group.

To do so:

  1. View an epic.
  2. In the right sidebar, in the Labels section, select Edit.
  3. Select Create group label.
  4. Fill in the name field. You can't specify a description if creating a label this way. You can add a description later by editing the label.
  5. Select a color by selecting from the available colors, or enter a hex color value for a specific color.
  6. Select Create.

Edit a label

{{< history >}}

  • Minimum role to edit a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project or group.

Edit a project label

To edit a project label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Next to the label you want to edit, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), and then select Edit.
  4. Select Save changes.

Edit a group label

To edit a group label:

  1. In the top bar, select Search or go to and find your group.
  2. Select Manage > Labels.
  3. Next to the label you want to edit, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), and then select Edit.
  4. Select Save changes.

Delete a label

{{< history >}}

  • Minimum role to delete a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

[!warning] If you delete a label, it is permanently deleted. All references to the label are removed from the system and you cannot undo the deletion.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.

Delete a project label

To delete a project label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Next to the Subscribe button, select ({{< icon name="ellipsis_v" >}}), and then select Delete.

Delete a group label

To delete a group label:

  1. In the top bar, select Search or go to and find your group.

  2. Select Manage > Labels.

  3. Either:

    • Next to the Subscribe button, select ({{< icon name="ellipsis_v" >}}).
    • Next to the label you want to edit, select Edit ({{< icon name="pencil" >}}).

  4. Select Delete.

Archived labels

{{< history >}}

  • Introduced in GitLab 18.3 with a flag named labels_archive. Disabled by default.
  • Changed flag labels_archive so it can be turned on and off for a group in GitLab 18.7.
  • Generally available in GitLab 18.11. Feature flag labels_archive removed.

{{< /history >}}

You can archive labels that are no longer actively used but need to be preserved for historical perspective and search purposes.

For example, you might archive release labels like Q4-25 after a release is complete, keeping them available for searches while removing them from the label selection dropdown list.

When you archive a label:

  • The label is hidden from the label selection dropdown list in issues, merge requests, and epics.
  • The label remains visible on existing issues, merge requests, and epics where it was previously assigned.
  • You can still search for the label and view historical data.
  • The label appears in a separate Archived tab on the Labels page.

Archive a label

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project or group.

To archive a label:

  1. In the top bar, select Search or go to and find your project or group.
  2. Select Manage > Labels.
  3. Next to the label you want to archive, select Edit ({{< icon name="pencil" >}}).
  4. Select the Archived checkbox.
  5. Select Save changes.

The label is archived and deprioritized.

View archived labels

To view archived labels:

  1. In the top bar, select Search or go to and find your project or group.
  2. Select Manage > Labels.
  3. Go to the labels page for your project or group.
  4. Select the Archived tab.

Unarchive a label

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project or group.

To unarchive a label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Select the Archived tab.
  4. Next to the label you want to unarchive, select Edit ({{< icon name="pencil" >}}).
  5. Clear the Archived checkbox.
  6. Select Save changes.

Promote a project label to a group label

{{< history >}}

  • Minimum role to promote a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

You might want to make a project label available for other projects in the same group. Then, you can promote the label to a group label.

If other projects in the same group have a label with the same title, they are all merged with the new group label. If a group label with the same title exists, it is also merged.

[!warning] Promoting a label is a permanent action and cannot be reversed.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project's parent group.

To promote a project label to a group label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Next to the Subscribe button, select the three dots ({{< icon name="ellipsis_v" >}}) and select Promote to group label.

All issues, merge requests, issue board lists, issue board filters, and label subscriptions with the old labels are assigned to the new group label.

The new group label has the same ID as the previous project label.

Promote a subgroup label to the parent group

{{< history >}}

  • Minimum role to promote a label changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

It's not possible to directly promote a group label to the parent group. To achieve this, use the following workaround.

Prerequisites:

  • There must be a group that contains subgroups ("parent group").
  • There must be a subgroup in the parent group, that has a label you want to promote.
  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for both groups.

To "promote" the label to the parent group:

  1. In the parent group, create a label with the same name as the original one. You should make it a different color so you don't mistake the two while you're doing this.

  2. In the subgroup, view its labels. You should see the two labels and where they come from:

  3. Next to the subgroup label (the old one), select Issues, Merge requests, or Epics.

  4. Add the new label to issues, merge requests, and epics that have the old label. To do it faster, use bulk editing.

  5. In the subgroup or the parent group, delete the label that belongs to the lower-level group.

You should now have a label in the parent group that is named the same as the old one, and added to the same issues, MRs, and epics.

Generate default project labels

{{< history >}}

  • Minimum role to generate default labels changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

If a project or its parent group has no labels, you can generate a default set of project labels from the label list page.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.
  • The project must have no labels present.

To add the default labels to the project:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Select Generate a default set of labels.

The following labels are created:

  • bug
  • confirmed
  • critical
  • discussion
  • documentation
  • enhancement
  • suggestion
  • support

Scoped labels

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Teams can use scoped labels to annotate issues, merge requests, and epics with mutually exclusive labels. By preventing certain labels from being used together, you can create more complex workflows.

A scoped label uses a double-colon (::) syntax in its title, for example: workflow::in-review.

An issue, merge request, or epic cannot have two scoped labels, of the form key::value, with the same key. If you add a new label with the same key but a different value, the previous key label is replaced with the new label.

<div class="video-fallback"> See the video: <a href="https://www.youtube.com/watch?v=7l7tnEva6I8">Scoped Labels - Setting up your Organization with GitLab</a>. </div> <figure class="video-container"> <iframe src="https://www.youtube-nocookie.com/embed/7l7tnEva6I8" frameborder="0" allowfullscreen> </iframe> </figure>

Filter by scoped labels

To filter issue, merge request, or epic lists by a given scope, enter <scope>::* in the searched label name.

For example, filtering by the platform::* label returns issues that have platform::iOS, platform::Android, or platform::Linux labels.

[!note] Filtering by scoped labels not available on the issues or merge requests dashboard pages.

Scoped labels examples

Example 1. Updating issue priority:

  1. You decide that an issue is of low priority, and assign it the priority::low label.
  2. After more review, you realize the issue's priority is higher increased, and you assign it the priority::high label.
  3. Because an issue shouldn't have two priority labels at the same time, GitLab removes the priority::low label.

Example 2. You want a custom field in issues to track the operating system platform that your features target, where each issue should only target one platform.

You create three labels:

  • platform::iOS
  • platform::Android
  • platform::Linux

If you assign any of these labels to an issue automatically removes any other existing label that starts with platform::.

Example 3. You can use scoped labels to represent the workflow states of your teams.

Suppose you have the following labels:

  • workflow::development
  • workflow::review
  • workflow::deployed

If an issue already has the label workflow::development and a developer wants to show that the issue is now under review, they assign the workflow::review, and the workflow::development label is removed.

The same happens when you move issues across label lists in an issue board. With scoped labels, team members not working in an issue board can also advance workflow states consistently in issues themselves.

For a video explanation, see:

<div class="video-fallback"> See the video: <a href="https://www.youtube.com/watch?v=4BCBby6du3c">Use scoped labels for custom fields and custom workflows</a>. </div> <figure class="video-container"> <iframe src="https://www.youtube-nocookie.com/embed/4BCBby6du3c" frameborder="0" allowfullscreen> </iframe> </figure>

Nested scopes

You can create a label with a nested scope by using multiple double colons :: when creating it. In this case, everything before the last :: is the scope.

For example, if your project has these labels:

  • workflow::backend::review
  • workflow::backend::development
  • workflow::frontend::review

An issue can't have both workflow::backend::review and workflow::backend::development labels at the same time, because they both share the same scope: workflow::backend.

On the other hand, an issue can have both workflow::backend::review and workflow::frontend::review labels at the same time, because they both have different scopes: workflow::frontend and workflow::backend.

Receive notifications when a label is used

You can subscribe to a label to receive notifications whenever the label is assigned to an issue, merge request, or epic.

To subscribe to a label:

  1. View the label list page.
  2. To the right of any label, select Subscribe.
  3. Optional. If you are subscribing to a group label from a project, select either:
    • Subscribe at project level to be notified about events in this project.
    • Subscribe at group level to be notified about events in the whole group.

Set label priority

{{< history >}}

  • Minimum role to set label priority changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

Labels can have relative priorities, which are used when you sort issue and merge request lists by label priority and priority.

When prioritizing labels, you must do it from a project. It's not possible to do it from the group label list.

[!note] Priority sorting is based on the highest priority label only. Issue 14523 considers changing this.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project.

To prioritize a label:

  1. In the top bar, select Search or go to and find your project.
  2. Select Manage > Labels.
  3. Next to a label you want to prioritize, select the star ({{< icon name="star-o" >}}).

This label now appears at the top of the label list, under Prioritized Labels.

To change the relative priority of these labels, drag them up and down the list. The labels higher in the list get higher priority.

To learn what happens when you sort by priority or label priority, see sorting and ordering issue lists.

Lock labels when a merge request is merged

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed
  • Status: Beta

{{< /details >}}

{{< history >}}

  • Introduced in GitLab 16.3 with a flag named enforce_locked_labels_on_merge. This feature is beta. Disabled by default.
  • Minimum role to lock labels changed from Reporter to Planner in GitLab 17.7.

{{< /history >}}

[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history. This feature is available for testing, but not ready for production use.

To comply with certain auditing requirements, you can set a label to be locked. When a merge request with locked labels gets merged, nobody can remove them from the MR.

When you add locked labels to issues or epics, they behave like regular labels.

Prerequisites:

  • You must have the Planner, Reporter, Developer, Maintainer, or Owner role for the project or group.

[!warning] After you set a label as locked, nobody can undo it or delete the label.

To set a label to get locked on merge:

  1. In the top bar, select Search or go to and find your group or project.
  2. Select Manage > Labels.
  3. Next to the label you want to edit, select the vertical ellipsis ({{< icon name="ellipsis_v" >}}), and then select Edit.
  4. Select the Lock label after a merge request is merged checkbox.
  5. Select Save changes.

Audit events for labels

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

GitLab records audit events when you create, update, or delete project and group labels. Use these events to track label changes for debugging or compliance purposes.

The following label actions generate audit events:

  • label_created: A project or group label is created.
  • label_updated: A project or group label is updated. When the title changes, the audit message includes the old and new title (for example, Changed label title from Foo to Bar). For other field changes, the message is generic (for example, Updated label Foo).
  • label_deleted: A project or group label is deleted.

[!note] Labels that GitLab creates automatically, for example during Jira imports, do not generate audit events. Only labels created through direct user action are audited.