How to stop GitLab email notifications without missing a review

GitLab notifies by email, and on a busy project that adds up fast: comments, pushes, pipelines, reassignments. The fix is a handful of settings, set in the right order, so the noise stops and review requests still reach you. Here is how GitLab’s notification settings work in 2026, from the broadest to the most specific.

Where the settings are

Select your avatar in the upper-right corner, then Preferences, then Notifications in the left sidebar. There you set:

• Global notification email: where notifications go. It defaults to your primary email address.
• Global notification level: the default for every group and project you haven’t set yourself.
• Receive notifications about your own activity: off by default. Leave it off unless you want copies of your own comments and changes.
• Groups and Projects: a level for each one you belong to, and for each group an email address.

You can also change a group or project from its own page, with the notification dropdown next to the bell icon.

The six notification levels

Level	What you get by email
Global	Your default level, or the nearest one set above it
Watch	Most activity
Participate	Items you take part in: you commented, edited, were mentioned, assigned or asked to review
On mention	When someone mentions you in a description or a comment
Custom	Items you take part in, plus the events you select. Some events only come if you select them, even on items you take part in
Disabled	Nothing

Which setting wins

The most specific one: a project’s level overrides its group’s, and a group’s overrides your global level. A project or subgroup set to Global doesn’t jump straight to your global level, though. It takes the nearest level set above it: its parent group, then the groups above that, and your global level last. So if your global level is Watch and a subgroup is set to Participate, a project in that subgroup set to Global gets Participate.

A setup that cuts most of the noise

1. Global: Participate. You still hear about merge requests you’re assigned to, asked to review, comment on or are mentioned in. At this level GitLab also emails you about each new push to a merge request you take part in.
2. Watch only what you own. Watch sends most activity, so keep it for the one or two projects where you want everything.
3. On mention or Disabled for the rest: big groups you only follow, and projects you no longer work on.
4. Mute single threads. At the top of an issue’s or merge request’s right sidebar, select Notifications off. It unsubscribes you from that item only. Notifications on does the opposite, for an item you aren’t part of.
5. Give a client’s group its own address. Each group can send to a different one of your email addresses, so a client’s projects land in their own inbox.

Why you get an email for every pipeline

Two different settings send pipeline email:

• Your notification level. Pipeline emails go to the person who started the pipeline: at Watch for failed and successful pipelines, and at Custom only for the events you select, such as Pipeline fails. At Custom, select Pipeline fails and clear Pipeline is successful to keep the failures and drop the successes, and keep the merge request events you still want selected.
• The Pipeline status emails integration. A project or group can email every pipeline’s status to a list of addresses, set in Settings › Integrations › Pipeline status emails. Someone with the Maintainer or Owner role for the project, or Owner for a group, can select Notify only broken pipelines or Notify only when status changes, or limit it to certain branches.

Filter what’s left

Notification emails carry headers your mail app can filter on: List-Id with the project’s path, X-GitLab-Project and X-GitLab-Project-Path, and X-GitLab-NotificationReason, which is own_activity, assigned, review_requested, mentioned or subscribed. The reason also appears in the email’s footer. A rule that keeps review_requested, assigned and mentioned in your inbox and files the rest is usually enough. To turn those into phone alerts, see how to get GitLab push notifications on your phone.

Stop all of it

1. Select your avatar, then Preferences, then Notifications.
2. Set Global notification level to Disabled.
3. Clear Receive notifications about your own activity.
4. Set every group and project you belong to to Global or Disabled.

Some email still arrives. GitLab always sends security emails, for example when an SSH key is added, your password changes, two-factor authentication is turned off, or a personal access token is created, revoked or about to expire. On GitLab Self-Managed and Dedicated, administrators can still email you, and they can switch off some of the always-sent emails for the whole instance.

For a single item, the unsubscribe link at the bottom of every notification email works too. If you’re signed in to GitLab it unsubscribes you at once; if not, it asks you to confirm. Mail apps that show an Unsubscribe button use the email’s List-Unsubscribe headers instead, which unsubscribe you from that item directly.

Your To-Do List doesn’t change

Notification levels decide email, not to-dos. The one exception: at Custom, selecting Merge request you’re eligible to approve is created also gives you a to-do when you can approve a merge request. A review request, an assignment, a mention, or a failed pipeline or merge conflict on your merge request still adds a to-do. So you can turn email down hard and still catch everything that needs you, as long as something watches the To-Do List. More in the GitLab To-Do List explained.

MergeBell does that watching. It sends a push for each new to-do: checked every five minutes on the free tier, every minute on Pro, or within seconds with Instant mode, with Mark done and Open on the notification. It is on Google Play for Android, with iPhone coming soon.