GitLab To-Do List explained: what creates a to-do, and how to clear it

Email tells you everything that happened. The To-Do List tells you what needs you. If you work in GitLab every day, it is the single most useful screen in the product — and the one most people leave at 87 unread. Here is exactly how it fills up and empties, per GitLab’s documentation as of GitLab 19.5.

What creates a to-do?

GitLab adds an item to your To-Do List when:

• an issue or merge request is assigned to you;
• your review is requested on a merge request;
• you are mentioned in the description or a comment of an issue, merge request or epic — or in a comment on a commit or a design;
• the CI/CD pipeline of your merge request fails;
• an open merge request can’t be merged because of a conflict, and you are its author or the person who set it to auto-merge;
• a merge request you added to a merge train is removed from it;
• someone requests access to a group or project you own.

You can also add one yourself: Add a to-do item on any issue or merge request.

Since GitLab 17.8, every mention creates a new to-do, even in a thread where you already have one. Other kinds of to-do stay at one per item.

What marks a to-do done on its own?

Acting on the item usually clears it. GitLab marks your to-do done when you:

• add an emoji reaction to the description or a comment;
• add or remove a label;
• change the assignee or the milestone;
• close the issue or merge request;
• comment;
• edit the description;
• resolve a design discussion thread;
• accept or deny an access request.

These do not clear it: linking another item, adding a child item, tracking time, assigning yourself, or changing an issue’s health status.

When a merge request is merged or closed, GitLab marks done the to-dos of everyone involved — assignees, reviewers and approvers — including failed-pipeline to-dos. That is why a review you never got to can disappear on its own.

How do you clear the rest?

• Mark as done. From the list, or from the upper-right corner of the issue or merge request itself. Changed your mind? The Done tab can restore it.
• Snooze (GitLab 17.9 and later). For one hour, until later today, until tomorrow at 8 AM local time, or until a date and time you choose. Snoozed items wait on the Snoozed tab and return to the list when the time comes, marked with when they were first created.
• Bulk edit (GitLab 17.10 and later). Select several items — or all of them — and mark them done or snooze them in one go.

A routine that keeps it at zero

1. Check it twice a day, not continuously. Most to-dos are not urgent; review requests and failed pipelines are the ones that block someone.
2. Act, snooze or mark done — nothing else. Every item leaves the list on the first touch. If you cannot act now, snooze it to a real time rather than leaving it in place.
3. Do the review requests first. Someone is waiting on each of them, and a review that sits for a day costs the author context.
4. Fix the source, not the symptom. If one project floods you with mentions, ask the team to mention less, or take yourself off its groups — email settings will not stop to-dos.

The To-Do List on your phone

The To-Do List is the reason a phone is useful for GitLab at all: it is short, it is personal, and almost everything on it can be finished in a minute. MergeBell’s inbox is built on it — your to-dos grouped by project, swipe to mark one done with an undo, Mark all done with a five-second undo — and its push alerts fire when a new to-do appears, free every five minutes or every minute on Pro. More on that in how to get GitLab push notifications.