> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Your Triage view
> Read a Triage card, cut the queue to just what's yours, and arrange it — with views, filters, grouping, layouts, and saved views.
export const OpenBetaBadge = ({tip = "This feature is currently in open beta. We are actively improving it based on your feedback. If you encounter any issues or have suggestions, please share them on our Discord community or visit the support page.", title = "Open Beta", cta = "Contact support", href = "/support", disabled = false}) => {
return
{title}
;
};
export const TeamPlanBadge = ({tip = "This feature is available on Team (formerly Pro+), Advanced, and Enterprise. Please refer to our pricing page for more information about our plans and features.", title = "Team Plan", cta = "Read more", href = "https://coderabbit.ai/pricing", disabled = false}) => {
return
{title}
;
};
export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => {
return
{title}
;
};
|
Triage gives you one cross-repository queue and four independent controls to work it: a **view** decides which pull requests are in play, **filters** and **search** narrow that set, **grouping and ordering** arrange what is left, and the **layout** decides how it is drawn. A [saved view](#saved-views) captures all four at once. This page walks the surface — the card, the queue, and how you tune it to fit you.
## 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.
A card is a **projection**, not a live window onto your provider. CodeRabbit maintains it from provider events and its own review results, so it stays current without polling GitHub on every page load. It can lag briefly — see [Signal freshness](#signal-freshness).
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.
Selecting a card opens it in [Change Stack](/pr-reviews/change-stack) when available, or the provider otherwise.
### Always shown
These fields cannot be turned off:
| Field | What it shows |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Repository, number, title, author, age | Which pull request this is. |
| **Priority** | `P0`, `P1`, `P2`, `P3`, `Close candidates`, `No priority`, or `Untracked`. See [How Triage prioritizes](/triage/prioritization). |
| **Priority reasoning** | A short explanation of why this pull request is ranked where it is. **Show full priority reason** expands truncated text; **View priority reason** in the card menu opens all of it. |
| **Next action** | The single most useful thing to do next — see [Next action](#next-action). |
| **GitHub Actions** | The check-status indicator — see [Check status](#check-status). |
| **Diff size** | Lines added and removed, as `+120` / `−45`. |
| **Reviewers** | Avatars of the people on the pull request, up to three, with a `+N` when there are more. |
### What you can toggle
Open **Display > Display properties** and toggle any of these. Your choice is remembered per view and stored in [saved views](#saved-views).
| Property | What it shows |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Review state** | The provider's review decision — see [Review state](#review-state). |
| **Last activity** | `Last activity: 3 hours ago`, and so on. |
| **CodeRabbit review status** | Whether CodeRabbit's review is in flight, behind newer changes, or missing: `CodeRabbit is reviewing`, `New changes since last review`, or a reason there is no current review, such as `Draft pull request`, `Reviews paused`, or `Review failed`. On by default, and hidden when there is nothing to act on, which is most cards. Hover for the reason and what to do about it. |
| **Change type** | `Bugfix`, `Feature`, or `Refactor`. |
| **Review guidance** | How deeply CodeRabbit suggests reviewing this: `Quick review`, `Standard review`, `Deep review`, or `Review later`. |
| **Risk** | Residual risk after CodeRabbit's review: `Low risk`, `Medium risk`, `High risk`, or `Unknown risk`. |
| **Security risk** | Security architecture risk: `Minimal`, `Low`, `Moderate`, `High`, or `Critical security risk`. Defined in [Security Architecture Review](/security/architecture-review). |
| **Issue severity** | The severity of the issues CodeRabbit raised: `High`, `Medium`, or `Low`. |
| **Blast radius** | How far the change reaches: `Low`, `Medium`, or `High blast radius`. Defined in [Security Blast Radius](/security/blast-radius). |
| **Review effort** | `Low effort`, `Medium effort`, or `High effort`, from CodeRabbit's [estimated review effort](/pr-reviews/walkthroughs#estimated-review-effort). Hover for the underlying percentage. |
**Security risk** is offered only to organizations with [CodeRabbit Security](/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](/triage/actions) for what each one does when clicked.
| Next action | What it means |
| ---------------------------- | --------------------------------------------------------------------------------------------- |
| `Start review` / `Re-review` | Nobody has reviewed the current code yet. |
| `Review` | Open it in [Change Stack](/pr-reviews/change-stack) and review it. |
| `Respond to feedback` | A reviewer left something the author has not answered. |
| `Update PR` | The author needs to change the code before this can move. |
| `Fix CI` | Checks are failing. |
| `Fix merge conflicts` | The branch conflicts with its base. |
| `Refresh branch` | The branch is behind its base and needs updating. |
| `Auto Fix` | CodeRabbit can address the outstanding review feedback itself. |
| `Find reviewer` | Nobody is assigned who can review this. |
| `Ping in Slack` | A reviewer is assigned but has not acted. |
| `Review and decide` | A judgment call from a maintainer, not a line-by-line review. |
| `Merge` | Approved and nothing mechanical is blocking it. |
| `Close PR` | Appears stale or superseded. See [close candidates](/triage/prioritization#close-candidates). |
| `Follow` | Nothing to do yet; track it in Slack instead. |
| `Open in GitHub` | Triage cannot act on this one from here. |
The card's action menu also offers **Ping in Slack** where enabled for your organization — see [Ping a channel or group DM](/triage/actions#ping-a-channel-or-group-dm).
### Review state
The provider's review decision, shown as a colored label:
| Label | Meaning |
| ------------------- | ------------------------------------------- |
| `Approved` | The pull request has the approval it needs. |
| `Changes requested` | A reviewer asked for changes. |
| `Review required` | Review is still needed before merging. |
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:
| State | Meaning |
| -------------------------------------------------- | -------------------------------------------------------------------- |
| `Passed` | Every check that reported has passed. |
| `Failed` | At least one check failed. A failure outranks work still running. |
| `In progress` | At least one check is still running. |
| `Neutral` | Checks finished without a pass or fail outcome. |
| `No checks` | The pull request reports no checks. |
| `Check status not loaded` / `Loading check status` | Triage has not fetched details yet. Open the indicator to load them. |
Open the indicator for the full list — see [View check details](/triage/actions#view-check-details).
A visible failure is reliable evidence. The absence of one is weaker: a check list can be truncated or time out while loading, and the card does not distinguish "all checks passed" from "as many checks as we could read passed". Before merging on a green indicator, confirm in the provider.
### 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 as `Untracked`. 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:
| View | What it shows |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Requires my action** | Pull requests you authored, plus pull requests you are reviewing — as a requested reviewer, a reviewer, an approver, or someone who asked for changes — that may still have something waiting on you. Where CodeRabbit cannot tell, the pull request is included rather than hidden. This is where you land by default. |
| **All PRs** | Every tracked, open pull request you can see, across every repository. |
| **Close candidates** | Pull requests carrying a [close recommendation](/triage/prioritization#close-candidates) you have not already parked. |
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**.
Each view remembers its own grouping, ordering, and card properties. **Requires my action** and **All PRs** start grouped into **Focus** lanes and ranked by priority within each lane. **Close candidates** starts grouped by repository and ordered oldest-first.
## 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.
| Filter | Values |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Repository name** | Any repository in the queue |
| **PR author** | Any author in the queue |
| **PR reviewers** | Any reviewer on a pull request in the queue |
| **Priority** | `P0 · Urgent`, `P1 · High priority`, `P2 · Medium priority`, `P3 · Low priority`, `Close candidates`, `No priority` |
| **Review workflow** | `New changes, unreviewed by CodeRabbit`, `Awaiting human review`, `Action required by the author`, `Ready to merge`, `Other` |
| **Review guidance** | `Quick`, `Standard`, `Deep`, `Later` |
| **Risk** | `High`, `Medium`, `Low` |
| **Security risk** | `Critical`, `High`, `Moderate`, `Low` |
| **Change type** | `Bugfix`, `Feature`, `Refactor` |
| **Title** | Free text, matched as substring against titles only — unlike search, it ignores repository names and pull request numbers. Tick **Exclude matching titles** to invert it, which is the one exclusion Triage offers. |
**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](#saved-views).
## 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:
| Group by | Sections you get |
| ----------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Workflow** | `Not reviewed by CodeRabbit`, `Awaiting human review`, `Waiting on author`, `Ready to merge`, `Untracked`, `Other` |
| **Priority** | `P0` through `P3`, plus `Close candidates`, `No priority`, and `Untracked` |
| **Security risk** | The five risk levels, plus `No current Security review` |
| **Repository** | One section per repository, busiest first |
| **Author** | One section per author, busiest first |
| **Focus** | `Now` and `Next` — see [Focus lanes](#focus-lanes) |
| **None** | One flat list |
**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:
| Lane | What is in it |
| -------- | ---------------------------------------------------------------------------------- |
| **Now** | As much of the top of the ranked queue as fits within the author's daily capacity. |
| **Next** | Everything beyond that. |
"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:
| Signal | On a new push |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Change type, issue severity, blast radius, security risk | Hidden until CodeRabbit reviews the new commit. |
| Review effort, risk, review guidance | Kept — these describe the change as a whole and survive a push. |
| Review state | Reflects the provider. An approval that no longer covers the latest commit stops being labeled. |
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
See how these signals combine into a priority, and how to override one when you disagree.
Act on the queue you just built, without leaving it.
Get your view delivered as a digest, and act on it without opening the app.