GitLab Slack Test Works but Merge Request Notifications Missing

You configure the official GitLab for Slack app, open your project settings, and click the Test button. A bright green message lands in your designated Slack channel. The webhook connection is alive, the OAuth token is valid, and the channel ID matches. Ten minutes later, a developer opens a real merge request, and the channel stays silent.

This gap between a passing test and real-world silence is one of the most common problems with GitLab integrations. A passing test only proves that GitLab can post static text to a Slack webhook. It proves nothing about your merge request trigger pipeline, your filtering rules, or channel permissions for asynchronous bot events.

When your GitLab Slack test works but merge request notifications are missing, you need a process of elimination. Isolate event triggers, label scopes, target branches, and channel memberships without disrupting active team channels or creating phantom reviews.

Why a passing test does not prove real MR events will post

The Test button inside GitLab integrations sends a synthetic test payload. When you test the settings, GitLab sends a test notification over the configured integration path. This verifies that Slack accepted the HTTP request and that your credentials are valid. It verifies transport, not logic.

A real merge request passes through a chain of conditionals before any payload leaves GitLab. First, the event generator must capture the database write when an author clicks Create Merge Request. Second, the integration evaluates filter rules: target branch matching, draft status, and applied labels. Third, the notification dispatcher looks up the destination channel mapped to the Merge Request event, which can differ from your default channel. If any step fails or evaluates to false, GitLab drops the notification silently. It never posts an error back to Slack.

Webhook transport differences also play a role. A manual test click runs in an active web request thread or an immediate background job with elevated privileges. If background workers hit backpressure or queue delays, notifications stall. On self-hosted instances, proxy firewalls or security software sometimes intercept webhooks from worker nodes while allowing requests from the web frontends. Don't treat the green test banner as proof that your production events work.

Set up a controlled, non-sensitive MR reproduction

Never debug notification pipelines by repeatedly editing real merge requests on your main branch. You spam your colleagues and leave confusing audit logs on sensitive code. Build a controlled reproduction in your repository instead.

Start by creating a disposable test branch from your default branch: git checkout -b test-slack-notifications. Push a trivial change, such as a whitespace adjustment in a markdown file or a dedicated test file. Open a new merge request against your default branch (main or master). Give it a clear title like 'Test: Slack Notification Verification' and make sure the 'Mark as draft' checkbox is unchecked.

Keep the description simple, assign the MR to yourself, and leave the labels empty for your initial baseline test. This creates a clean event. If you need to debug in an active project without disturbing the main channel, open your integration settings and temporarily set the Merge Requests channel to a private debugging channel where only you and the GitLab Slack bot are members.

Watch Slack the moment you click Create Merge Request. If the notification doesn't appear within sixty seconds, keep that merge request open. You'll use this exact MR to test label additions, comments, and approvals step by step, instead of creating a dozen new branches.

Check event selection: is the Merge request trigger actually enabled?

The simplest reason a test succeeds while MR alerts fail is that the Merge Request event trigger is turned off in the project settings. The integration test message fires regardless of which checkboxes you have selected under the Trigger section.

Open your project in GitLab and go to Settings > Integrations > GitLab for Slack. Scroll past the connection details to the Triggers list. The app's notification events include pushes, issues, merge requests, notes, and pipelines, among other events. Find the 'Merge request' checkbox and confirm it's checked. If it's unchecked, GitLab sends push events and pipeline alerts while silently ignoring all MR actions.

Pay close attention to group-level inheritance. If your project sits inside a group that enforces integration defaults, check whether your project inherits those group settings or keeps a custom override. You can review how group settings interact with repository overrides in this guide on GitLab Slack integration group defaults. If the parent group manages the Slack integration, project maintainers might find the triggers locked in an unchecked state, or their project-level changes may get wiped out during a sync. Confirm the trigger is explicitly enabled and saved at the tier that governs your project.

Check Labels to be notified and branch settings (only where GitLab docs say they apply)

GitLab lets teams restrict notifications so chat channels don't get flooded by every repository event. Misconfigured filters here cause frequent notification drops.

Inside the GitLab for Slack settings, inspect the 'Labels to be notified' field. The official documentation says this field restricts notifications to merge requests and issues that carry specific labels. If someone entered 'review-ready' or 'frontend' in this field, GitLab checks every new MR against that list. If your test merge request lacks every required label, the integration ignores it. If you want to route notifications by functional team or label, see our article on how to route GitHub PRs and GitLab MRs to Slack channels by label. To fix missing alerts during diagnosis, clear the Labels field entirely, save the integration, and test your reproduction MR again.

Next, examine the 'Branches for which notifications are to be sent' setting. This dropdown usually defaults to 'All branches', but teams often tighten it to 'Default branch', 'Protected branches', or a custom regular expression like '^(main|release-.*)$'. If a developer opens a merge request from a feature branch into a temporary staging branch that isn't protected, GitLab suppresses the notification. Make sure your reproduction MR targets a branch your branch filter covers.

Confirm the receiving channel, then link out for access and inheritance issues

The test notification uses the channel in the primary channel field or the channel selected when you ran the test. Real merge requests use the specific input field next to the Merge Request trigger checkbox if your configuration splits events across multiple channels.

Verify that the channel name in that field matches an existing channel in your workspace. Double-check for typos, missing prefixes, or outdated naming conventions. If you use channel IDs (such as C0123456789) instead of plain names like #dev-reviews, confirm the ID belongs to the right workspace. When the target channel is private, the GitLab Slack bot must be an explicit member. A bot can't post to a private channel just because an admin configured the webhook. In Slack, open the destination channel, type '/invite @GitLab' (or the exact name of your GitLab Slack app bot user), and press Enter.

If you still hit permission failures or unexpected routing across sub-groups, your workspace may have bot authorization drift. Review our checklist on GitLab Slack integration channel permissions to audit your workspace tokens. Teams migrating between self-hosted webhooks and the official app also run into routing conflicts. If legacy webhooks are competing with the app, read our guide to fix GitLab Slack duplicate notifications during migration.

Keep a diagnostic log: what to record at each step

Troubleshooting integration webhooks across multiple platforms gets chaotic fast without written notes. Don't change five settings at once. Track each modification in a simple diagnostic table.

Set up a log with five columns: Timestamp, Setting Changed, Target Channel, MR State, and Slack Output. A clean diagnostic session looks like this:

1. 14:02 UTC | Clicked Test button in GitLab UI | #test-alerts | N/A | Received green test payload.

2. 14:05 UTC | Opened unlabelled MR targeting main | #test-alerts | Draft: No, Target: main | No message received.

3. 14:08 UTC | Cleared 'Labels to be notified' field | #test-alerts | Draft: No, Target: main | No message received.

4. 14:12 UTC | Ran '/invite @GitLab' in Slack | #test-alerts | N/A | Slack confirmed bot joined channel.

5. 14:14 UTC | Added comment to existing test MR | #test-alerts | Comment posted | Notification card appeared immediately.

If you manage a self-hosted GitLab instance, cross-reference this log with your production logs. Inspect /var/log/gitlab/gitlab-rails/exceptions_json.log and /var/log/gitlab/sidekiq/current on your GitLab host. Look for errors containing 'Gitlab::HTTP::BlockedUrlError', 'Slack::API::Errors', or 403/404 HTTP return codes from the Slack API. If your instance can't send payloads out of your internal network at all, walk through our guide on self-hosted GitLab Slack webhook troubleshooting to check your local network and outbound proxy allowances.

When the official app is not the right tool: one updating card per MR with MergeMe

Even when the official GitLab for Slack app works exactly as designed, engineering teams hit notification fatigue. The official app creates a brand-new Slack message for nearly every event. It posts a message when an MR opens, another when someone comments, another for pipeline updates, and another when someone pushes a commit. Channels quickly turn into an unreadable wall of bot notifications.

MergeMe fixes this by replacing noisy multi-message feeds with one updating card per PR/MR. Instead of spamming the channel with separate posts for review events, MergeMe keeps a single Slack message per merge request and updates it in place.

MergeMe is built for engineering teams that coordinate in Slack, including mixed GitHub and GitLab teams, self-hosted GitLab enterprises, and engineering managers who want clarity without notification sprawl. It supports GitHub.com, GitLab.com, and self-hosted GitLab, posting into your Slack workspace from a single platform. The Hobby plan includes 1 channel mapping and 5 user mappings, while the Team plan starts at £5 per developer seat monthly with a 10-seat minimum. For enterprises behind strict firewalls or managing internal data residency and SSO requirements, a self-hosting option is available by enquiry.

Conclusion

A passing Slack integration test means only that your webhook endpoint is reachable. If your merge request notifications are missing, audit your MR trigger toggles, clear restrictive label filters, verify target branch protections, and make sure the Slack bot is invited to the target channel.

Once your notifications flow, don't let your engineering channels drown in disconnected bot alerts for every comment and build step. Switch to MergeMe for one updating card per merge request across GitLab.com, self-hosted GitLab, and GitHub in one Slack workspace. Start on the free Hobby tier or deploy it on your own infrastructure, and give your team clean, actionable code reviews today.