Your dashboard

Overview

Your dashboard is the screen that tells you what to do next. It keeps an inbox of the things waiting on you — reviews you owe, work assigned to you, a deployment waiting on your approval — and most items leave on their own the moment the thing that put them there is settled, so an empty inbox means you are genuinely clear rather than that you stopped looking. Alongside it sit a timeline of what happened, a summary of your open work, and flow metrics for any repository or group you can see.

Everything here is a read except four small writes on the inbox itself: mark an item done, snooze it, bookmark something, or throw an item away. Nothing on this page changes a merge request, a work item or a pipeline — the dashboard points you at them and you act there.

Before you start

How it works

The dashboard asks four questions at once, and each has its own surface with its own rules.

An inbox item is a condition, not a message

An item is one row per thing that is true about you right now — "you have been asked to review this merge request", not "somebody asked you to review this merge request at 09:12". Two consequences follow, and together they are the whole design.

Repeats collapse. Being asked twice to review the same merge request is one item that moves back to the top, not two items, and being mentioned twice on the same work item is likewise one item. Some conditions are deliberately finer-grained: a rejected review is keyed per reviewer, because two people asking for changes are two things to address; a failed completion criterion is keyed per criterion, because two failing criteria are two things to fix; and a deployment gate is keyed per node, because two gated nodes in one run are two decisions.

Items leave on their own. When the condition clears, the item is marked done without you touching it. Approve the review and your item goes; merge the request and every reviewer's item goes with it. A bookmark is the one reason with no clearing condition at all — it waits until you clear it. A mention has none of its own either, and goes only when the work item it was left on closes.

Done and removed are different. Marking an item done says I have dealt with this, and only a later event for the same condition brings it back. Removing it says get this off my screen, and because nothing is left to compare against, the very next matching event — including a redelivery of the one that created it — puts it back. Removing a review request does not decline the review.

A snooze does not detach an item from its condition. Snooze a review request, then approve the merge request, and the item is done rather than waiting to reappear. Waking is not a scheduled job either: an item whose snooze time has passed simply reads as pending on your next request.

The platform never puts your own actions in your own inbox. Commenting on your own work item does not raise an item for you, and neither does mentioning yourself.

The inbox is a surface, not a delivery channel. Nothing in it is emailed or pushed to you; you read it, and it decays to empty on its own as the conditions behind it settle.

What puts an item in front of you

Each item carries a reason, which is what makes an inbox skimmable rather than a pile of links.

Marking an item done clears it sooner than any of that, and for a bookmark it is the only thing that ever will. A deployment gate that names no approvers raises no item at all — an unnamed gate is open to anyone with Developer on the repository, which is not a list to put anything in front of.

Five more values are accepted by the reason filter and match nothing, because no condition produces them: review_approved, mr_unmergeable, mr_commented, blocked_by_resolved and pipeline_failed. Filtering on one is a valid request that returns an empty page.

Access is checked on every read, not on a schedule

An item names its target and copies nothing from it — no title, no body, no snapshot of anybody's name. Who caused it is read live as well, through the account as it stands now. Every read of the inbox, including the badge count, re-checks that you can still see each item's target, so losing access to a repository takes its items out of your very next response with no sweep in between. Because nothing is copied, an item can never show you a stale title, and a renamed or moved target reads correctly when you open it.

Removal is the one deliberate exception. It matches on the item's id and your ownership alone, which is what lets you clear an item whose target you can no longer open.

Feeds are chronological by when things happened

An activity entry is stamped with the source event's own clock, so a delayed event lands in the feed where it belongs in time rather than at the top. Feeds keep 90 days; the daily counts behind insights are permanent, so activity that has aged out of the feed is still counted in every metric.

How to

See what needs you

The inbox comes back most-recently-touched first, and by default it shows only what is pending — including anything whose snooze has expired. Narrow it with state (pending, snoozed, done or all), with one or more reasons, and with the kind of thing an item points at (merge_request, issue, pipeline_run, repository or group). Unknown filter values are refused rather than quietly ignored, so a filter that returns rows is a filter the platform understood.

Show the pending count

The badge is a separate, cheap read: a total plus a breakdown by reason, so a navigation bar can render "7" and a tooltip saying which seven without loading the list. It counts to 100 and then stops — past that, truncated is true and the number is a floor.

Mark an item done

Marking done is the ordinary way to empty the inbox of things nothing else is going to clear — a bookmark, a mention on a work item that is staying open, an item you have decided to handle later in some other system. Doing it twice is harmless and returns the same item.

Snooze an item until later

Snoozing hides an item until a time you choose, between one minute and 90 days from now, given as an RFC-3339 timestamp. Past ninety days you are not deferring the item, you are ignoring it, and marking it done is the honest way to say so.

A snoozed item still resolves automatically. If the merge request merges while the item is hidden, it goes to done rather than coming back.

Bookmark something to come back to

This is the one write where you choose the target: a merge request, a work item, a pipeline run, a repository or a group you can view, saved into your own inbox with the reason marked. The body carries the target's kind and the fields that kind needs, plus an optional note of up to 280 characters saying why you saved it — the only free text the inbox stores, and it is your own.

Bookmarking the same thing twice is refused with 409 rather than creating a second copy, and a target you cannot view answers 404 — the same answer a target that does not exist gives, so nothing leaks.

Remove an item from your inbox

Removal is the escape hatch for an item you can no longer see: if you lost access to a repository, its items vanish from your listings but still occupy a slot against your inbox limit, and removing them by id is how you get that slot back.

Read your headline numbers in one request

The summary is the envelope a dashboard renders before any content arrives: your pending attention count and its breakdown, how many merge requests you have open, how many reviews are waiting on you, how many work items are assigned to you, how many pipeline runs failed in the last 7 days, your current contribution streak, whether your getting-started checklist is finished, and a line per namespace with its plan and storage use.

The badge and the four counters beside it stop at 100. The response names every one that reached the ceiling in a truncated list and echoes the ceiling itself as count_cap, so a client can render "100+" without hardcoding a number the platform owns. Your contribution streak is not one of the capped counters; it is measured over the trailing year. The response enumerates at most 10 namespaces, and truncated says so when there are more.

Review what you did

Your own feed spans every group you can reach and defaults to the trailing 30 days. Filter it by domain — merge_request, issue, repository, release or pipeline — and set an explicit window with from and to in RFC-3339. A window may span at most 366 days. The member domain is accepted and matches nothing, because membership changes raise no feed line.

Entries carry a kind that says what happened: opened, merged, closed, reopened, reviewed, review_withdrawn, reviewer_added, reviewer_removed, retargeted and restacked on merge requests; opened, closed, reopened, assigned, unassigned, commented, criterion_failed, criterion_verified, regressed and verified on work items; pushed on repositories; created and published on releases; run_succeeded, run_failed, run_cancelled and run_timed_out on pipelines. One push is one entry however many branches it moved, with the branch detail in the entry's metadata.

Look at somebody else's activity

A profile feed shows what a person did, filtered by what you can see — so two people reading the same profile see different feeds, and neither sees anything they could not already open. A person whose work is all in repositories you cannot reach returns an empty page rather than a refusal; only an account that does not exist answers 404.

Your own feed and a profile feed are already one person's work, so the actor filter narrows nothing on either of them. It is the repository and group feeds where it earns its place.

Follow one repository's timeline

A repository's feed is every domain in one stream: merge requests, work items, pushes, releases and pipeline runs. Narrow it to one person with actor when you want to know what a single contributor did in one place.

Follow a whole group

A group's feed covers the group and every group and repository beneath it, however deep. A group routinely mixes public, internal and private repositories, so the feed is filtered per line: being a Reporter on the parent shows you the parent's activity, not the private repositories underneath it.

See where your time went

Where you have been most active over a window, busiest first, each entry with the split behind the total: commits, merge requests, reviews, releases and work items. Most entries are repositories; a group appears when you have worked on something the group itself owns, such as a group-level work item. The default window is the trailing 30 days and the default page is the top 10, up to 25. Dates here are calendar days (YYYY-MM-DD), not timestamps, because the counts behind them are daily.

Measure a repository's flow

Repository insights answer how is work moving through here: merge requests opened, merged and closed; reviews submitted; work items opened and closed; pushes; releases published; pipeline runs total, succeeded and failed. You get a total per metric, a bucketed series you can plot at day, week or month, means for time-to-merge, time-to-first-review and run duration, and a count of distinct contributors. The window is calendar days, to is inclusive, and it defaults to the trailing 30 days.

Two DORA metrics come back under names that describe what was actually measured — release frequency per week, counting published, non-draft releases, and merge lead time, which is the median time from opening a merge request to merging it. Change failure rate and time to restore come back null, each with a machine-readable reason beside it in unavailable, because no honest number exists for them without a record of what was deployed. A confident wrong figure is worse than a gap.

Read exact cycle times

Means hide their tails, so the percentiles are a separate read: p50 and p95 for time to merge, time to first review, work-item cycle time and pipeline duration, each with the number of samples behind it. n matters — a median of seven merge requests should be read differently from a median of twenty thousand — and truncated tells you when the window hit the 20 000-row sample ceiling, meaning the percentiles cover only the most recent 20 000 rows and n stops there.

A duration with nothing measurable in the window reports n of 0 and omits both percentiles rather than reporting them as zero — an absent p50 and a p50 of zero are deliberately different answers.

Compare repositories across a group

Group insights roll the same metrics up over the group and everything beneath it, at any depth, filtered to the repositories you can see. Add breakdown=repository for a per-repository split of the totals, capped at the 25 busiest by merges, pushes and work items closed — the response sets breakdown_truncated when there were more, so a chart can say "the top 25 of 60" instead of presenting a slice as the whole.

The group read reports means and carries no merge lead time at all, because a median over a whole subtree means reading every merge request in it. When you want the median, ask a single repository for its cycle time.

Reference

Limits

Your inbox holds 2 000 items, counting every state — pending, snoozed and done alike. It is a flat platform limit and does not vary by plan, because an inbox belongs to a person rather than to a namespace and there is no tier to raise.

Only bookmarks are refused at the limit. At 2 000 items a bookmark returns 429 TOO_MANY_REQUESTS and nothing is created — there is no half-saved bookmark and no lost note. An item the platform raises makes room instead: it evicts your oldest already-done item, so an inbox full of things you have finished with never blocks new work reaching you. The single case where a platform item is dropped is an inbox where all 2 000 are still live, because nothing there is safe to evict.

To get room back, mark items done and remove the ones you no longer want. Items you can no longer see still hold a slot, so if you have lost access to a repository, remove its items by id — that is what removal is for.

The other bounds worth knowing, none of which varies by plan:

Troubleshooting

Related