Every result for "best GitLab Slack integration" is written by a vendor, and this one is too: we make PRFlow, one of the three options below, and PRFlow is a GitLab Technology Partner. So this post sticks to differences you can check. The right pick mostly depends on how busy your channels are and how much you want to build yourself.
The short version
- The native GitLab for Slack app is the default. It's free and there's nothing to host, but it posts a new message for every event.
- DIY GitLab webhooks give you full control. You build and run the receiver.
- PRFlow gives each MR one Slack entry that stays current: pipeline, approvals, unresolved threads. It suits teams whose MRs get lost in the channel.
The three options at a glance
"Message per MR" means one Slack message that is edited as the MR changes. "Message per event" means a new message each time something happens.
| Native app | DIY webhooks | PRFlow | |
|---|---|---|---|
| Slack model | Message per event | Whatever you build | Message per MR |
| CI/CD status | Per-event messages | If you build it | On the MR message |
| MR comments | Per-event messages | If you build it | Thread under the MR |
| Self-hosted GitLab | Admin enables it | Yes | Yes |
| Cost | Free | Free, plus hosting and upkeep | Free up to 3 users |
1. Native GitLab for Slack app: the default
This is GitLab's own integration. It's free on Free, Premium, and Ultimate, on gitlab.com and self-managed (GitLab for Slack app docs), and it also gives you slash commands and issue notifications. If you're starting from nothing, start here.
Two things to know. It posts one message per event, so a busy project fills a channel fast. That's the same behavior as the legacy Slack notifications integration, which GitLab removed in 19.0. And on self-managed, an administrator has to enable the app for the whole instance from a Slack app manifest before any project can use it (admin Slack app settings).
2. DIY GitLab webhooks: most control, most work
GitLab project webhooks fire on merge request and pipeline events and can POST them anywhere (GitLab webhooks docs). If you want to decide exactly what gets posted and where, this is the option. The cost is engineering time: the events don't arrive ready for Slack, so you host and run a receiver that formats them.
One limit trips people up. A Slack incoming webhook can only post a message. It can't edit one afterwards (Slack incoming webhooks docs), so a message that stays current as the MR changes needs a full Slack app, not only a webhook URL.
The bigger cost starts once it works. Whatever you build becomes a service your team runs, for as long as you use it:
- Someone patches it: the runtime, its dependencies, and the host it runs on.
- Someone runs its database too: backups, upgrades, and disk space.
- Someone notices when it's down. A notifier that fails quietly looks exactly like a quiet day in the channel, so it needs monitoring and an owner.
- Someone rotates the GitLab and Slack tokens before they expire, and updates the code when either API changes.
- Someone keeps it reachable from GitLab, which on a self-hosted instance usually means a firewall or proxy exception.
Each of these is a small job. Together they're a standing one, and they tend to land on whoever wrote the first version.
3. PRFlow: one live entry per MR
PRFlow is ours. It posts one Slack message per MR and keeps editing it as the MR moves: pipeline status, how many approvals are still needed, unresolved threads, and finally the merge. Comments written on the MR appear in a Slack thread under that message, so the discussion stays next to the MR it's about.
The problem it's built for is the MR that's ready and then sits there, because its link scrolled up the channel and nobody saw it. Each entry shows the MR's current state, so you can see what it's waiting for without opening it. You pick the channel and which repositories post there. It works on gitlab.com and self-hosted GitLab, and it's free for up to three users. The side-by-side with the native app goes into more detail.
Which should you pick?
- If you're starting out, or you want slash commands and issue alerts, use the native GitLab for Slack app.
- If you need custom formatting or routing and already run internal services, build on webhooks.
- If MRs keep getting lost in a busy channel and people have to ask twice for a review, try PRFlow.
For step-by-step setup of any of these, see the GitLab Slack integration guide.
Bottom line
Start with the native app. It's free, and it's enough until the per-event messages turn into something everyone mutes. After that, the real question is whether you want to run another service yourself. Try two options on one project for a week and see which channel people actually read.