How to get GitLab push notifications on your phone

By Melih Toksari, developer of MergeBell · Updated 16 October 2026 · 3 min read

The single most useful thing a phone can do for a developer is tell you when it is your turn: a review was requested, someone asked you a question, or the pipeline on your branch just broke. GitLab does not do that on its own. Here is what it does do, and the four ways to get real push notifications on Android or iPhone.

What does GitLab send out of the box?

Email, and nothing else that reaches your phone directly.

Notification levels. For each group or project you choose Global, Watch, Participate, On mention, Custom or Disabled, and GitLab emails you accordingly.
Pipeline emails (failed, fixed, successful) go to the person who started the pipeline, depending on their level.
Your To-Do List is separate. Notification settings do not decide what lands there — a review request creates a to-do even if you turned its email off.
Native push is still a request. Issues asking for browser and mobile push notifications are open on GitLab’s tracker, with no delivery date.

Option 1: Filter GitLab’s email into a push

Every GitLab notification email carries an X-GitLab-NotificationReason header. Its value is one of own_activity, assigned, review_requested, mentioned or subscribed, and the same reason appears in the email’s footer.

If your mail app can filter on headers or footer text, send review_requested, mentioned and assigned to a folder or label that notifies you, and keep everything else quiet. It is free and works everywhere. The catch: you still cannot act from the email, and filters break the day your mail client changes.

Option 2: Slack or Microsoft Teams

The GitLab for Slack app posts merge request and pipeline events to a channel and adds slash commands. Microsoft Teams receives GitLab events through a webhook and a Power Automate workflow. Both are good for team awareness — “the deploy failed” in a shared channel — and weak for personal queues, because a channel cannot tell your review request from everyone else’s.

Option 3: Webhooks to a service you run

Project webhooks (free on every tier; group webhooks need Premium) fire on merge request events — opened, updated, approved, merged — and on pipeline status changes. A small service of your own can turn the ones you care about into pushes. You get full control, and you also get a server to keep running and secure, and the job of deciding which events are really yours.

Option 4: A GitLab app that watches your To-Do List

GitLab already decides what needs you: that is your To-Do List. It gains an item when you are assigned, when your review is requested, when you are mentioned, when your merge request’s pipeline fails, and when it hits a conflict. (Full list: the GitLab To-Do List explained.) An app that checks that list and sends a push for each new to-do gets the personal queue exactly right.

This is how MergeBell’s alerts work:

A separate, read-only key. Turning alerts on asks GitLab for a second grant with the read_api scope. MergeBell’s alert server checks the scopes and refuses any key that could write. Your sign-in token never leaves your phone.
How fast: free accounts are checked every five minutes; Pro checks every minute, and Instant mode adds a project webhook that rings the server within seconds. The webhook is a doorbell: its contents are discarded and the server re-reads your to-dos with the read-only key.
Buttons that act. A notification has Mark done and Open. Pro’s pipeline watches send “Pipeline failed” with Retry, which runs on your phone with your own token — after Face ID on iPhone, or once the phone is unlocked on Android.
Instances behind a VPN that the server cannot reach get checks on the phone instead, clearly labelled, when the phone’s system lets the app run.
Hide titles keeps merge request titles out of the server’s notifications entirely.

Other apps with push include Comeet (through its own proxy server), Greenlight: CI (gitlab.com only) and OctoLab on F-Droid — see the best GitLab apps for Android and iPhone.

Which option should you use?

You want	Use
Zero setup, no new apps	Email filters on `review_requested` and `mentioned`
The team to see failed deploys	GitLab for Slack app, or Teams
Full control and you run servers anyway	Webhooks to your own service
A push for your review queue, with buttons	A GitLab app that watches your To-Do List

Whichever you choose, give the notifier the least access it needs. A key that can only read is enough to know when it is your turn.

Frequently asked questions

Does GitLab have push notifications?

No. GitLab notifies by email, and integrations can post events to Slack or Microsoft Teams channels. Requests for native push notifications are open on GitLab's issue tracker. Push to a phone needs a third-party app or a service you run.

How do I get notified when someone requests my review in GitLab?

GitLab emails you, with the X-GitLab-NotificationReason header set to review_requested, and adds a to-do to your To-Do List. A GitLab app that watches your To-Do List can turn that into a push notification within minutes.

Can I get GitLab notifications without giving an app write access?

Yes. Watching your to-dos only needs a key with the read_api scope. MergeBell's alert server accepts only read-only keys and refuses anything that could approve, merge or push.

Why do I have a GitLab to-do but no email?

Notification settings and the To-Do List are separate. Turning an email notification level down does not stop to-dos from being created, so the To-Do List is the more reliable signal of what needs you.