GitLab Reviewer Notifications: Email Settings and Slack Alerts

An engineer opens GitLab, assigns you as a reviewer on an urgent merge request, and waits. Two hours pass before anyone notices. You never received a Slack ping, your inbox stayed silent, and the author assumed you were ignoring the review request.

This breakdown happens weekly on engineering teams running GitLab. The confusion comes from misunderstanding how the platform is built.

When a developer complains that GitLab reviewer notifications failed, they could be diagnosing a misconfigured personal email level or an unchecked box in the project integration triggers. Fixing the breakdown means untangling these two layers.

Two systems, two jobs: personal notifications versus the Slack channel integration

Your personal profile settings and your project Slack integrations run on distinct code paths inside GitLab. Personal notifications are outbound messages directed at a specific user account. They fire based on your user profile email address, your notification level, and your direct involvement with the issue or merge request.

Project integrations run through webhooks. When an event fires on a repository, the project-level Slack integration packages the payload and pushes it to an incoming webhook URL or a Slack app bot. The integration does not inspect your personal email preferences. It does not check whether you muted notifications on the repository. It only checks whether the project trigger for merge request events is enabled and which channel is configured to receive it.

This separation creates common blind spots. A developer can have their personal notification settings dialed to Custom with every reviewer event checked, yet receive zero Slack alerts because the project integration points to an archived channel. Conversely, a public engineering channel can get flooded with merge request updates while the assigned reviewer receives nothing in their private inbox because their global notification level is set to Disabled.

Treat them as two separate pipelines. The personal system tells an individual that work needs their attention. The chat integration broadcasts repository activity to a shared team surface. Teams that confuse the two end up adjusting project webhooks when an engineer simply muted their own profile.

Assignee, reviewer and eligible approver: who GitLab treats as what

GitLab keeps strict distinctions between assignees, reviewers, and eligible approvers. Conflating these three roles is the fastest way to misconfigure alerts.

An assignee is the person responsible for driving the merge request forward. This role usually writes the code, responds to feedback, and handles the actual merge. A reviewer is an individual requested to inspect the diff and leave comments.

Eligible approvers are a third category, defined by merge request approval rules. You might be listed as an eligible approver because you belong to an engineering group required by CODEOWNERS, yet never be explicitly selected as an assignee or reviewer. Being an eligible approver does not make you a reviewer in the notification engine. GitLab will not alert you just because you have the authority to approve an MR. Someone has to add you to the Reviewers field or mention your handle in a comment.

Personal notification rules treat assignees and reviewers differently. When someone adds you as an assignee, GitLab dispatches an assignee change event. When someone adds you as a reviewer, GitLab dispatches a reviewer change event. If your custom notification profile enables assignee notifications but leaves reviewer notifications unchecked, adding you to the Reviewers box generates zero personal emails. Check which field your team uses during your pull request review handoff before blaming the mail server.

Personal settings: notification email, global, group and project levels, and the custom reviewer events

Personal notification settings in GitLab follow a hierarchical cascade: Global, Group, and Project. A setting at a lower level completely overrides settings above it.

Your global setting lives under User Settings > Notifications. Here you specify your notification email address. If you use a corporate email for commits but an unmonitored address as your primary notification address, alerts route to the unmonitored inbox. Check this field first.

GitLab provides several notification levels: Global, Disabled, On Mention, Participating, Watch, and Custom. Participating is the default for most users. At that level, you only receive notifications on merge requests where you are directly involved: author, assignee, mentioned in a note, or added as a reviewer. But if you or your administrators switched your group or project level to Custom, you have to verify the exact checkbox state.

Under Custom notification settings, GitLab shows explicit toggles for merge request actions. Look for two entries: New merge request and Reviewer changed. If Reviewer changed is unchecked, GitLab will not notify you when a colleague adds you to the review list. If you set a parent group to Custom and unchecked this box, every project inheriting from that group suppresses your reviewer alerts unless you set a project-specific override.

Audit the cascade directly. If an engineer claims they do not receive emails for MRs, open the specific project page, click the bell icon next to the clone button, and inspect the level. If it says Global, check their profile level. If it says Custom, verify that Reviewer changed is checked.

Slack channel alerts: which merge request events the project integration triggers on, and what it does not promise

The standard GitLab Slack integration operates at the project or group level. When you go to Settings > Integrations > GitLab for Slack app or Slack notifications, you configure triggers that push messages into designated channels.

The Merge request events trigger fires on broad lifecycle steps: when a merge request is opened, closed, merged, or reopened. With this trigger active, GitLab sends a message to the target Slack channel containing the MR title, author, branch names, and current assignees. In newer releases, it also shows the assigned reviewers.

Here is what the standard GitLab Slack integration does not promise: a direct user ping for reviewers. If the Slack app has no verified mapping between GitLab usernames and Slack user IDs, your reviewers see their name in channel text without getting an unread ping or badge counter. To see how name matching works across platforms, read our guide on how to fix broken @mentions in Slack for code review.

The standard project integration also posts a distinct message for each lifecycle trigger. If an author opens a draft MR, updates the description, and adds three reviewers one by one, the channel gets a stream of separate notifications. The native project integration is a broadcast pipe. It does not replace personal triage, and it cannot make your reviewers look at the channel message.

Check your own settings read-only with the notification settings API

Instead of clicking through deeply nested web menus to diagnose missing alerts, query GitLab's REST API. The Notification Settings API lets you inspect your exact notification level and email configuration without modifying anything.

You can query your global notification settings with a personal access token scoped to read_user:

curl --header "PRIVATE-TOKEN: your_token" "https://gitlab.example.com/api/v4/notification_settings"

This call returns a JSON payload showing your notification_email, your current level (for example, participating or custom), and the boolean values for custom events. If you are debugging a specific repository, query the project endpoint by passing the URL-encoded project path:

curl --header "PRIVATE-TOKEN: your_token" "https://gitlab.example.com/api/v4/projects/my-group%2Fmy-project/notification_settings"

Read the response carefully. If level returns custom, scan the events object. You need to see:

"events": { "new_merge_request": true, "reopen_merge_request": true, "close_merge_request": true, "merge_merge_request": true, "merge_when_pipeline_succeeds": false, "reviewer_changed": true }

If reviewer_changed returns false or null under a custom level, your personal profile is dropping reviewer notifications. The API gives you ground truth. It cuts through cache issues, UI confusion, and misremembered group inheritance in two seconds.

Test it safely with a second consenting teammate: a step-by-step reproduction and how to read the result

Don't test reviewer notifications alone. GitLab has deliberate suppression logic: the platform never notifies you of actions you perform yourself. If you create a merge request and assign yourself as a reviewer, GitLab suppresses the notification email and will not ping you. Testing requires a cooperating teammate.

Run this test sequence in order:

Step 1: Coordinate with your testing partner. Confirm their primary email inbox is accessible and they are present in the test Slack channel.

Step 2: Have your teammate push a throwaway branch to the target project and open a draft merge request. Ask them to leave the Reviewers field blank at first.

Step 3: Have your teammate add your username to the Reviewers field on the merge request. Record the exact timestamp.

Step 4: Check your personal email inbox. You should receive an email within 60 seconds with a subject line saying you were added as a reviewer. If no email arrives, check your spam folder, then check the notification settings API outlined in the previous section.

Step 5: Check your Slack channel. Look for the project notification. Does the message appear? If it does, does it contain your name under Reviewers? Does that name generate a native Slack desktop notification, or is it plain unlinked text? If the channel is completely silent, the project integration trigger is disabled or misconfigured. For integration issues, see our troubleshooting guide for when a GitLab Slack test works but merge request notifications are missing.

This reproduction pinpoints the failure. If email arrives but Slack is silent, your personal settings are correct and the project webhook failed. If Slack gets the message but your inbox is empty, your personal settings or spam filter blocked the notification.

Decision guide: when to fix email, when to fix the channel, and where a per-MR card fits

Once you isolate the break, pick the fix that matches how your team works. Forcing email triage on a chat-first engineering group will not speed up code review.

Fix email when your developers work mostly from asynchronous inboxes and rely on GitLab To-Do lists. If engineers check their inbox every morning to triage code reviews, set global notification defaults to Participating and make sure notification emails match their corporate addresses. This setup needs little maintenance and does not clutter team communication channels.

Fix the project Slack channel integration when your team coordinates releases and deployments out of a central operational room. If you need visibility into code movement across the whole team, project-level channel webhooks give you that shared log. But project channel feeds break down once an engineering organization grows past ten developers. Several developers creating, updating, and reviewing merge requests will flood the channel with dozens of disconnected messages, drowning out actionable review requests.

When a noisy channel makes developers mute chat alerts entirely, consider replacing event-stream notifications with an updating card. MergeMe provides Slack notifications for GitHub pull requests and GitLab merge requests, shown as one updating card per PR/MR. Instead of posting separate messages, MergeMe updates a single card in place.

Engineering managers at 5 to 40 person teams often find that broadcast channels fail because developers cannot tell what needs action. A single updating card keeps the channel readable and keeps reviewers aware of pending work.

Conclusion

GitLab reviewer notifications don't have to be a guessing game between hidden profile menus and silent Slack webhooks. Personal email rules handle individual alerting, while project integrations handle team visibility. Once you know which layer owns the handoff, you can fix slow review pickup in minutes.

If your engineering team coordinates in Slack and struggles with noisy, multi-message feeds on merge requests, simplify the workflow. MergeMe replaces fragmented event alerts with one updating card per MR across GitLab.com, self-hosted GitLab, and GitHub. Connect your repositories, keep your channels clean, and give reviewers clear visibility. Try MergeMe on the free Hobby plan or start your team deployment today at https://mergeme.dev.