Skip to main content
| Triage answers two different questions about every pull request, and keeps the answers separate:
  • Priority — how much it is worth acting on this, compared to everything else in the queue.
  • Next action — what specifically has to happen for it to move.
Keeping them apart is deliberate. A pull request with failing CI is blocked, which tells you what to do about it, but that alone does not make it important. A trivial dependency bump with red checks should not outrank a customer-facing fix that is simply waiting for a reviewer. So mechanical state drives the next action, and value drives the priority.

What goes into a priority

Triage combines a small set of concrete signals into a base score, then lets people and policy override it. The precedence, from highest to lowest, is: The base score is calculated from three signals:
Automatic P0 requires external evidence. A pull request is ranked P0 automatically only when it carries a validated linked issue at High or Urgent priority in Jira or Linear. Without that, the base score is capped at P1 no matter how severe the internal signals look. This requirement applies only to CodeRabbit’s own ranking: an administrator rule can assign P0 without a linked issue, and a person can still set P0 manually — see Set a priority.
Blockers do not raise priority. Failing checks, merge conflicts, draft status, a branch behind its base, unresolved review threads, and a stale approval all shape the next action and can make a pull request un-mergeable. They are not what makes it urgent.

Administrator rules

Priority Guidance lets an administrator describe, in plain language, how the organization wants pull requests ranked. CodeRabbit turns that description into an ordered list of rules, each assigning a level from P0 to P3. A rule can match on facts Triage already has about a pull request, such as:
  • The repository, its owner, or the target branch
  • Draft state, change type, issue severity, risk, security risk, blast radius, and review effort
  • Check status, merge-conflict status, the workflow state, and the next action
  • Who is involved in it, optionally in a specific role such as author or requested reviewer
  • Words in its title or review context
  • How many other pull requests are blocked behind it
Rules cannot match labels, file paths, CODEOWNERS, team membership, assignees, or the code itself. When part of your description asks for something rules cannot express, CodeRabbit reports that part as unsupported and does not apply it, rather than approximating it. These Priority Guidance rules affect ranking. Triage automation rules are configured separately and perform actions such as merging, closing, repairing, or sending reminders. Their repository filters can use labels and file paths, and their conditions can use team membership.

Priority levels

Triage does not show a numeric score. Levels are the interface; the number behind them is not, and is deliberately not documented, because it changes as the ranking model improves. Two pull requests in the same provider state routinely land on different levels — that is the point. Same state, different issue severity, different linked-issue priority, different amount of work stuck behind them.

Why this one is here

Each card carries a one-line priority reasoning explaining its rank. Triage picks the most specific explanation it has:
  1. A comparative explanation — why this pull request ranks where it does relative to others. Triage rejects an explanation that only restates mechanics (that checks are failing, that the branch needs a rebase), because that describes the next action, not the priority.
  2. The CodeRabbit review summary — used only while it covers the latest reviewable commit. A summary describing an older commit is never shown as the reason.
  3. A signal-specific sentence — for example, that the change is release-blocking, or that it offers high value relative to review effort.
  4. The next-action text — the fallback when nothing more specific applies.
Long reasoning is shortened on the card. Show full priority reason expands it in place, and View priority reason in the card menu opens the whole thing.

Close candidates

A close candidate is not a low priority — it is a different recommendation. It means the evidence suggests the pull request should be reviewed for closing, not reviewed for merging. You can select Close candidates from the priority badge on a tracked, open pull request and provide a required reason. Selecting P0–P3 instead removes the close recommendation. See Set a priority. Triage automatically nominates one when:
  • It duplicates or is superseded by other work, and it has since gone quiet.
  • It looks abandoned and is blocked — no meaningful human activity, and something is in its way that nobody is clearing.
  • Its base has moved so far that the change no longer applies — the branch is many commits behind and old enough that the assumptions it was written against have changed.
Automatic nominations exclude pull requests that are watched or pinned, carry a security or incident signal, are release-critical, or carry known high risk. These safeguards govern CodeRabbit’s recommendations; a manual selection records your own decision. In the Close candidates view, open the information icon on a card to read its Reason to close. For a manual recommendation, this shows the saved reason and who provided it. The manual recommendation remains until someone changes the priority; it does not expire with an agent assessment.
A close recommendation does not close the pull request. Close it manually, or configure and enable a close rule to automate closure for matching PRs after notice.
For what happens when you close, ignore, or reject a close candidate, see Close a pull request.

When a priority changes

The base score and the CodeRabbit verdict are recomputed on evidence changes, not on a clock and not when you open the page. Specifically:
  • A new commit lands and CodeRabbit re-reviews it, changing the issue severity.
  • The linked Jira or Linear issue changes priority, or a link is added or removed.
  • Enough pull requests merge or open behind this one to move it into a different blocker band.
  • An administrator changes a Priority Guidance rule that applies to this pull request.
  • Someone sets or changes a manual priority.
Opening Triage displays the last stored priority rather than waiting on a recalculation or making live Jira, Linear, or GitHub calls, so a card can briefly reflect the state from before a very recent change. The next background refresh reconciles it. Merges elsewhere in the repository can also move things. After a pull request merges into the default branch, Triage re-examines the other open pull requests in the repository: some are now duplicated or superseded, some have drifted far enough from their base to matter, and the blocker counts behind others have changed. So a pull request you did not touch can be ranked differently in the morning.

What’s next

Your Triage view

Look up what each signal on a card means, and group or filter the queue by any of them.

Actions on a pull request

Act on what the ranking surfaced — review, repair, reassign, or close.