"GitLab Slack integration" sounds like one feature. It isn't — it's a small family of methods, and the right one depends on where your GitLab lives and how much channel noise you can stand. In 2026 the question got sharper, because the way many teams did this for years (the legacy Slack notifications integration) no longer exists: GitLab 19.0 removed it. So the first thing to settle isn't "how do I set it up" but "which method is still supported." This guide compares the four, honestly.
The 60-second version
- There are effectively four ways to integrate GitLab with Slack: the native GitLab for Slack app, the legacy notifications/slash-commands integrations (both removed in 19.0), DIY project webhooks, and third-party tools.
- If you upgraded and your channel went quiet, that's expected: GitLab 19.0 removed the legacy Slack integrations. The replacement is the native app, set up fresh — there's no automatic migration.
- The native GitLab for Slack app is free, works on gitlab.com and self-managed, and supports 15+ event types and slash commands. Downside: a separate message per event, no single updating message per MR, no comment threading.
- DIY webhooks work for simple "ping the channel" needs but can't edit or thread messages without building a real OAuth Slack app — a genuine engineering project, not no-code.
- Third-party tools consolidate the per-event spam into one review-centric surface per MR; you pick on form factor and how much GitLab access you'll grant.
The four ways to connect GitLab and Slack in 2026
- Method 1 — Native GitLab for Slack app. GitLab's official, recommended app. Free, both editions, slash commands plus per-event notifications. The best default for most teams.
- Method 2 — Legacy Slack notifications and slash commands. The old project-level integrations. Covered for completeness because people still search them, but both are removed in 19.0 — don't start here.
- Method 3 — DIY via GitLab project webhooks. Maximum control, zero per-seat cost, but you build and maintain the glue. Honest about where "no-code" breaks down.
- Method 4 — Third-party tools. Consolidate the native app's message stream into a review-focused surface. A trade-off, not a free lunch.
| Dimension | Native app | Legacy (removed) | DIY webhooks | Third-party |
|---|---|---|---|---|
| Supported in 2026? | Yes | No (gone in 19.0) | Yes | Yes |
| Cost | Free | — | Free at GitLab end; you host glue | Paid |
| Works self-managed? | Yes (since 16.2) | — | Yes | Yes (varies by tool) |
| Message model | One per event | One per event | One per event (DIY coalescing) | Consolidated |
| CI/CD status placement | Separate messages | Separate messages | Separate (correlate yourself) | On the MR surface |
| Comment threading | No | No | Only with OAuth app + state | Yes (e.g. PRFlow) |
| GitLab access | Linked user, write-capable | Webhook | Your tokens | Read-only or write (varies) |
| Setup effort | Low (SaaS) / Med (self-managed) | — | High | Low |
Method 1: The native GitLab for Slack app (recommended by GitLab)
The GitLab for Slack app is GitLab's own native Slack app. It adds per-event channel notifications, slash-command ChatOps, and a newer, experimental GitLab Duo chat. It's the sanctioned replacement for the removed legacy integrations, and it works on gitlab.com SaaS and self-managed/Dedicated (self-managed support since 16.2, per-instance GA in 17.8) across Free, Premium, and Ultimate.
What it gives you:
- 15+ event types: push, issue, merge request, note/comment, tag push, pipeline, wiki, deployment, group mention, incident, vulnerability, alert.
- Filters like "notify only broken pipelines" and "notify only when status changes", plus branch and label filtering.
- Up to 10 Slack channels per event, project aliases, and slash commands (
/gitlab ...) that run as your linked GitLab user.
The honest limitation that drives everything else: it sends a separate message for every event. One active MR — opened, each pipeline state, each comment, approval notes, merge — can generate many discrete messages. There's no single message per MR that updates in place, no persistent CI/CD status surface on one message, and no comment threading.
A note for the security-conscious: slash commands link your Slack identity to your GitLab user and can perform write actions (create or close issues, trigger deploys). That's power, but also blast radius — relevant when comparing to read-only tools later. Admins managing many repos get group-level install (GA since 17.8): configure once at the group and unconfigured subgroups and projects inherit it.
Method 2: Legacy Slack notifications and slash commands (removed in GitLab 19.0)
Bottom line first, for anyone who landed here looking for the old method: both legacy project-level integrations are gone in GitLab 19.0 (shipped to self-managed on May 21, 2026). If you're on 19.0+, these are not options. The legacy Slack integrations were removed in GitLab 19.0 — that post has the full upgrade angle.
People conflate two distinct things:
- "Slack notifications" — the service that posted MR, pipeline, and comment events to a channel via incoming webhook. Deprecated in 15.9 and listed as removed in 19.0 on the integration docs and the deprecations index (tracked in issue #435909).
- "Slack slash commands" — a separate, self-managed/Dedicated-only integration (it never existed on gitlab.com), removed in 19.0 and the one called out in GitLab's official 19.0 breaking-changes blog.
An accuracy caveat worth knowing: the "Slack notifications" removal appears on the integration doc and deprecations index but not in the 19.0 breaking-changes blog or release notes — so an operator checking only the blog could miss it. Verify against your own edition.
Migration reality: there's no in-place migration. The replacement is the GitLab for Slack app, set up fresh, and GitLab has acknowledged the app does not have full feature parity with the old notifications integration (#435909) — so granular per-label or per-branch routing may not map one-to-one.
Method 3: DIY with GitLab webhooks and Slack incoming webhooks
This is a roll-your-own pipe: GitLab project webhooks fire JSON on MR, pipeline, and comment events, and you relay it into Slack via a Slack incoming webhook. It's cheap and fully under your control for simple "ping the channel" needs — but GitLab's and Slack's JSON shapes differ, so you point the webhook at a transform layer rather than directly at Slack. Pipeline status lives in object_attributes.status on "Pipeline events"; merge request data comes on separate "Merge request events".
Now the honest part — where "no-code" collapses. Slack incoming webhooks can only create messages; they cannot edit or thread. Editing a message in place needs the chat.update Web API with a bot token plus stored channel and ts; threaded replies need the parent ts. So "one updating message per MR" and "comment-as-thread" require a real OAuth Slack app and persistent state — a genuine engineering project, not a webhook.
More gotchas to budget for:
- Each event is a separate POST — spam unless you add coalescing logic.
- MR events don't carry pipeline status, so CI-on-the-MR-message means correlating two event streams.
- Slack Workflow Builder triggers are paid-plan-only and read top-level JSON keys only — GitLab's nested payload needs flattening, so a proxy reappears.
- GitLab webhooks auto-disable after 4 consecutive failures (permanently after 40) with only ~2 days of request history, so a flaky receiver silently stops delivering.
Verdict: great for small, static notifications; a poor fit if you want rich, stateful behavior — at which point a maintained tool is usually cheaper than building and operating the glue.
Method 4: Third-party tools for richer MR notifications
This category replaces the native app's per-event stream with a consolidated, review-centric surface. The shared value is collapsing the 10+ messages a single MR can generate into one place: one message per MR that updates in place keeps the channel flat, with CI/CD status on that message and comments synced into a thread.
The access-model distinction that genuinely matters: read-only notifiers can post to Slack but can't act on GitLab; tools that let you merge, resolve discussions, or comment back from Slack inherently need write-capable access. Frame it as "minimal blast radius vs write-back actions", not good versus bad. And don't oversell "works with self-hosted" as a third-party edge — the native app also supports self-managed since 16.2. The real native gaps these tools address are consolidation and threaded comment sync, not self-hosting per se.
Full disclosure: we make PRFlow, which takes the simplest version of this approach — one Slack message per merge request that updates in place (no per-event spam), CI/CD pipeline status on that same message, and MR comments synced into a thread. It works on gitlab.com and self-managed, and stays read-only — only the read_api OAuth scope, never write. Compare it head-to-head: PRFlow vs the native GitLab Slack app.
Which one should you pick?
- Want the supported default at no cost and can live with per-event messages? Native GitLab for Slack app (Method 1).
- Drowning in per-event spam and want one clean, updating message per MR with CI status and threaded comments? A consolidation tool (Method 4).
- Have bespoke routing needs and the engineering time to build and run glue? DIY webhooks (Method 3), eyes open about state, threading, and silent-disable failure modes.
- Just upgraded to 19.0 and lost your notifications? You were on a legacy integration (Method 2) — set up the native app, or evaluate Methods 3/4. See the 19.0 upgrade deep dive.