To reduce GitLab merge request spam in Slack: open the project's GitLab for Slack app settings, clear the Trigger checkboxes your team never reads (Push, Tag push, Wiki page, Deployment), narrow what remains with the branch and label filters, put pipelines on Notify only broken pipelines, and send each remaining trigger to its own channel instead of one shared one. Then accept the ceiling: the app posts a separate Slack message for every event it does send, and no setting collapses several events into one message. Filters change how many events reach Slack. They never change the one-event-one-message rule.
The 60-second version
- Turn off Push, Tag push, Wiki page, Deployment. Pure volume for most channels.
- Merge request events also fire when a commit lands on the source branch, so MR noise survives turning Push off.
- Narrow what is left with Branches for which notifications are to be sent and Labels to be notified.
- Pipelines: Notify only broken pipelines plus Notify only when status changes.
- There is no filter for drafts, bots, or authors, and every event gets its own message.
Where the messages actually come from
The "our channel is unreadable" story usually starts the same way: someone turned on the GitLab for Slack app, ticked most of the boxes because they all sounded useful, and pointed them at one channel. The app's model is a list of triggers, each with its own set of destination channels. GitLab's documentation for the app lists these: Push, Issue, Confidential issue, Merge request, Note, Confidential note, Tag push, Pipeline, Wiki page, Deployment, Group mention in public, Group mention in private, Incident, Vulnerability, and Alert.
You configure them per project. From the docs: "In the top bar, select Search or go to and find your project," then "In the left sidebar, select Settings > Integrations," then "Select GitLab for Slack app." In the Trigger section you "Select the checkbox for each GitLab event you want to receive notifications for in Slack," and for each one you enter the destination channels, up to 10 names separated by commas.
One thing worth checking before you tune anything: which integration you are actually running. GitLab's docs for the older project-level Slack notifications integration now say plainly, "This feature was deprecated in GitLab 15.9 and removed in GitLab 19.1." (docs) If a project is still on that one, its settings are a dead end and the app is the migration target. Our guide to connecting GitLab and Slack walks through the options if you are setting this up from scratch.
Step 1: turn off the triggers nobody reads
Clear these checkboxes first. In a review channel they contribute volume and almost never change what anyone does:
- Push. One notification per push to the repository, merge request or not. On an active repo it is usually the largest single source of volume.
- Tag push. Useful in a release channel, noise in a review channel.
- Wiki page and Deployment. Both belong somewhere other than the channel where people review code.
- Note. Think before you clear this one. GitLab's webhook reference says comment events fire "when a new comment is made or edited on commits, merge requests, issues, and code snippets," so the Note trigger is not merge-request-specific. Turning it off silences review discussion and issue discussion together. (webhook events)
Issue and Confidential issue are the other common candidates. If your team tracks work in GitLab issues and reviews code in the same Slack channel, splitting those two streams into two channels does more for readability than any filter.
Step 2: why merge request noise survives turning off Push
This is the part that surprises people. Teams turn off Push, expect the per-commit chatter to stop, and it does not. GitLab's webhook events reference lists what fires a merge request event, and the list is longer than "opened and merged":
- A new merge request is created.
- An existing merge request is updated, approved (by all required approvers), unapproved, merged, or closed.
- An individual user adds or removes their approval.
- A reviewer is re-requested to review a merge request.
- A merge request is set to auto-merge, or auto-merge is canceled.
- A commit is added in the source branch.
- All threads are resolved on the merge request.
That sixth line is the one that matters. With the Merge request trigger enabled, every push to an open MR's source branch produces a merge request event, which produces a Slack message, whether or not the Push trigger is on. The payload's object_attributes.action is update in that case, the same value used when someone edits the description or changes a label. GitLab has no setting that says "notify on open and merge only" for this trigger. It is on or off.
Step 3: narrow what is left with the branch and label filters
Two filters apply across triggers rather than per trigger, and both live under the same integration settings page.
Branches for which notifications are to be sent is a dropdown. The
project integrations API
exposes it as branches_to_be_notified with four values: all, default, protected, and default_and_protected. It is a coarse instrument. It will keep feature-branch pushes out of a channel, and it will not tell an important merge request from an unimportant one.
Labels to be notified is the sharper tool. GitLab's docs describe it as "any or all of the labels a GitLab issue, merge request, or comment must have to receive notifications for," and "Leave blank to receive notifications for all events." The API pairs it with labels_to_be_notified_behavior, whose valid options are match_any and match_all. Used deliberately, this is the closest the app gets to filtering by intent: add a label like needs-review when an MR is genuinely ready, filter on it, and the channel stops carrying work in progress. The same trick is the only handle you have on bot merge requests, since filtering on a label bots never apply suppresses them.
One caveat before you build a label scheme on top of this. GitLab issue #387630, "Labels to be notified in Slack notifications integration not working," reports that the filter is respected for Note triggers while Pipeline triggers still fire for merge requests without the label. It was filed against the older Slack notifications integration rather than the app, so treat it as something to verify on one project rather than confirmed current behavior.
Step 4: quiet pipelines without losing the failures
Pipelines are the other big volume source, because every pipeline transition is an event. The app gives you two checkboxes for this, and they compose:
- Notify only broken pipelines limits pipeline notifications to failures. Green builds stop posting entirely.
- Notify only when status changes suppresses repeat notifications for the same status.
Both are in the app's notification settings and are documented on the same GitLab for Slack app page. The trade-off is real: with only-broken on, nobody learns from Slack that a build went green, which for many teams is exactly the signal they wanted. We went through the options for that in more detail in GitLab pipeline Slack notifications explained.
Step 5: split the stream across channels
Every trigger has its own channel field, so the app can fan out even though it cannot consolidate. The API parameter names show the granularity available: merge_request_channel, note_channel, pipeline_channel, push_channel, issue_channel, deployment_channel, and one for each of the remaining triggers. Point merge requests at the review channel, pipelines at a build channel, issues at a planning channel, and the review channel gets quiet without anyone losing information.
Two things to know about scope. The app is configured per project, so a per-team channel layout is per-project work. And when the app is installed at the group level, GitLab's docs say "the integration is also enabled for all subgroups and projects in the group that don't already have the integration configured" (generally available in GitLab 17.8) which means a group-wide default will not overwrite the projects you already tuned by hand, and equally will not fix them.
Noise sources, causes, and fixes
The same handful of symptoms come up over and over. Here they are with the setting that addresses each one.
| Symptom | Cause | Fix |
|---|---|---|
| A message for every commit | Push trigger on, and merge request events fire on new commits to the source branch | Clear Push; there is no partial fix for the merge request side |
| Dozens of pipeline messages a day | Pipeline trigger reports every status transition | Notify only broken pipelines plus Notify only when status changes |
| Every review comment lands in the channel | Note trigger covers comments on MRs, issues, commits, and snippets | Clear Note, or route it to a separate channel, and accept losing issue comments too |
| Draft MRs post before anyone can review them | No draft filter exists in the app | Filter on a label you add only when the MR is ready |
| Renovate and other bots flood the channel | No author or bot filter exists | Set Labels to be notified to a label the bots never apply |
| Unrelated projects share one channel | Group-level install with no per-project channels | Configure the integration per project with its own channel per trigger |
| Label filter set, pipelines still post | Reported gap in label filtering for pipeline triggers (issue #387630) | Turn the Pipeline trigger off in that channel and verify on one project |
What the app cannot filter
Four limits are worth knowing before you spend an afternoon in the settings page, because each one has a request on GitLab's own tracker rather than a hidden checkbox:
- Drafts. No setting suppresses notifications for draft merge requests. The request for one, issue #456848, puts the problem well: "significant developer activity in the early phase of a Merge Request can be very chatty and difficult for reviewers and observers to decide when to pay attention."
- Authors and bots. No user filter. Issue #581493 asks for one and describes the modern version of the problem: "When GitLab MR Comment webhooks are enabled, automated reviewers like @GitLabDuo generate many comments, causing excessive Mattermost/Slack notifications."
- Specific merge request actions. The Merge request trigger is one checkbox covering open, update, approval, unapproval, merge, and close. You cannot subscribe to "opened and merged" alone.
- Consolidation. Every event that passes the filters becomes its own message. The standing request to change that, issue #21573 ("Threaded notifications in Slack"), asks for "a single message, with threaded messages for updates" instead of a channel that receives "updates for lots and lots of individual detail."
Slack-side controls, and their limits
You can also push back from the Slack end, though these are per-person settings rather than a team fix. Slack lets each member set a conversation to All new posts or Just mentions, and muting a channel hides it from the sidebar while still badging mentions and DMs.
Both work. Both also mean the channel is no longer doing the job you built it for: a muted review channel does not get reviews done faster. Treat them as relief while you fix the source, and watch for the failure mode where the whole team has muted a channel that management still believes is the review workflow.
When to change the model instead of the settings
Do the arithmetic for one ordinary merge request. Opened, three pushes while the reviewer is asleep, five comments, four pipeline runs, one approval, one merge. Even with Push off, Note off, and pipelines set to broken-only, that MR crosses an enabled trigger six or seven times, and the app posts six or seven separate messages, scattered across hours and interleaved with every other MR in flight. Nobody scrolls back to reassemble the story. They scroll past.
At that point the useful question changes from "which trigger do I turn off" to "how many messages should one merge request produce." If the answer is one, the native app cannot get there, by design, and the honest options are a DIY webhook receiver that edits messages in place or a tool that already does it. We compared them in best GitLab Slack integration: 4 options compared.
Full disclosure: we make PRFlow, which takes the one-message approach. It posts a single Slack card per merge request and edits that same message as CI, approvals, and merge state change, while review comments arrive as threaded replies instead of channel messages. Routing is per rule rather than per project, so one rule can cover a whole GitLab group by pattern. It is read-only against GitLab and works on gitlab.com and self-hosted instances. If you want the trade-offs rather than the pitch, here is our comparison with the native GitLab for Slack app, which is also where we say what the native app does better.
Bottom line
Start with the two changes that cost nothing and remove the most: clear Push, and give pipelines their own channel with only-broken on. Then decide honestly whether the merge request trigger's all-or-nothing behavior is survivable for your repo volume. If it is, a label filter and a few channels will hold. If it is not, no combination of checkboxes will save the channel, because the limit is one message per event, and that is not a setting.