The card
A card is one open pull request. It carries three kinds of information — knowing which is which tells you how much to trust each:- Provider facts — title, author, review decision, check results. Read from GitHub.
- Review signals — risk, blast radius, issue severity, review effort. Produced during a CodeRabbit review of a specific commit, so they can be withdrawn when a newer commit lands.
- Triage’s own judgment — the priority, the next action, and the reasoning text. Derived from both of the above.
When a decision is expensive to get wrong — closing another contributor’s work, or merging — open the pull request and confirm the current state before you act.
Always shown
These fields cannot be turned off:What you can toggle
Open Display > Display properties and toggle any of these. Your choice is remembered per view and stored in saved views.Security risk is offered only to organizations with CodeRabbit Security review enabled. Organizations without it see Risk on by default instead.
Next action
Every card names one next action — not a list of options, the single step Triage believes moves this pull request forward. Most next actions are clickable; see Actions on a pull request for what each one does when clicked.
The card’s action menu also offers Ping in Slack where enabled for your organization — see Ping a channel or group DM.
Review state
The provider’s review decision, shown as a colored label:
Hover Approved or Changes requested to see how many reviews are behind the label. When an approval no longer covers the latest commit, no label is shown rather than a stale one.
Check status
The GitHub Actions indicator summarizes the latest check run:
Open the indicator for the full list — see View check details.
Merge conflicts and base drift
Triage tracks whether a branch conflicts with its base or has fallen behind it, but there is no separate conflict badge on the card. You see it through the next action instead —Fix merge conflicts for a real conflict, Refresh branch for a branch that is only behind — and through the repair action in the card menu.
Tracked and untracked
A pull request that CodeRabbit has no review context for is shown asUntracked. It appears in the queue and you can still act on it, but it carries no review signals, no review guidance, and no calculated priority. Repositories that CodeRabbit does not review produce untracked cards.
Built-in views
The rail down the left of the queue holds your views. Three are built in:
Every view is limited to pull requests that are open and tracked by CodeRabbit, in repositories you can access.
The two halves of Requires my action are not treated the same way. A pull request you authored always appears, because “nothing to do here right now” is itself worth knowing about your own work — and a stalled pull request of yours is the one most easily forgotten. A pull request you are only reviewing appears when the card offers you something to do; if you have already reviewed it and it is now waiting on CI or on its author, nothing is being asked of you and it would be misleading to list it under this heading. Where CodeRabbit cannot work out whether an action is waiting on you, the pull request is included rather than hidden, because “we cannot tell” is not the same as “there is nothing to do”. Nothing becomes unreachable either way: a pull request left out of this view is still in All PRs.
There is no separate “authored by me” view. Requires my action deliberately covers both your authoring and your reviewing, because in practice you want one queue rather than two. To narrow it to just your own pull requests, filter by PR author.
Search and filters
Search — the box at the top of the queue matches pull request titles,owner/repository names, and pull request references like #4312.
Filters — open Filter to narrow by any of these. Each is a multi-select: choosing several values matches any of them.
Clear filters removes all of them at once.
Filters live in the URL, not in your account. A filtered queue is a link you can paste to a colleague — and filters are not restored when you come back later. To keep a combination, save the view.
Grouping and ordering
Open Display to arrange the queue. Grouping splits it into labelled sections; Sub-grouping splits those again by a second field. Both offer:
Ordering sorts within each group by Priority, Last activity, Created, PR number, or Title, ascending or descending.
Grouping and ordering are applied to the whole queue before it is paged, so page two continues exactly where page one stopped rather than re-sorting a slice.
Sections can be collapsed, and a collapsed section stays collapsed as you move around. Hold Alt while collapsing to collapse every section at once.
List and board
List is one row per pull request, 100 to a page — the denser view, and the better one for reading down a ranking. Board is a column per group, 20 cards to a column, starting with six columns and loading more on request — the better one for seeing the shape of the queue, such as how much is waiting on authors versus waiting on reviewers. Switching layout does not change which pull requests are in the queue, only how they are drawn.Focus lanes
Grouping by Focus splits the queue into two lanes:
“Capacity” is not a setting anyone configures. Triage measures each author’s recent throughput — how much review-complexity their merged pull requests carried over the last 30 days — and fills Now from the top of the ranked queue until that budget is spent. Once something does not fit, everything after it goes to Next, including smaller work that technically would have fitted; the lane boundary is a line in the ranking, not a knapsack.
Because the ranking is different for each person, the same pull request can be Now for its author and Next for one of its reviewers. That is intended: each of you has a different queue and a different budget.
Team views
When team views are enabled for your organization, the rail carries a Teams section listing the GitHub teams you belong to. Selecting one scopes the queue to the pull requests where that team is a requested reviewer — the team’s review backlog, rather than everything its members happen to be involved in. Team views work inside All PRs only. Your team memberships are read from your own GitHub account and refreshed periodically; if your GitHub authorization has lapsed, Triage asks you to reconnect rather than showing you a partial list.Team views are rolling out per organization, so the Teams section may not be there yet.
Saved views
A saved view captures a whole working setup — filters, layout, grouping, ordering, visible card properties, and which sections are collapsed — under a name and an icon of your choosing. Saved views appear in the left rail below the built-in ones.- Save current view stores what you are looking at now.
- Update from current overwrites a saved view with your current setup; Rename and Delete do what they say.
- Saved views are personal. They belong to you within one organization and are not shared with your team.
- You can keep 50 of them, with names up to 100 characters. At the limit, Save current view is disabled until you delete one.
A saved view stores the definition, not the result. Reopening it re-runs its filters against the current queue, so it shows you what matches today — not the pull requests that happened to be there when you saved it.
Signal freshness
Review signals describe the commit CodeRabbit reviewed. When an author pushes a newer reviewable commit, Triage withdraws the signals that would be misleading rather than showing them against code they no longer describe:A card carries one freshness timestamp, but its fields arrive from different sources at different moments. A recent timestamp means something on the card was updated recently — not that every field on it was.
What’s next
How Triage prioritizes
See how these signals combine into a priority, and how to override one when you disagree.
Actions on a pull request
Act on the queue you just built, without leaving it.
Triage in Slack
Get your view delivered as a digest, and act on it without opening the app.