> ## 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.

# Triage prioritization

> Learn how Triage combines review state, activity, risk, effort, and dependency context to rank pull requests and recommend the next action.

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 <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="badge-alert" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const ProPlusPlanBadge = ({tip = "This feature is available as part of the Pro+ plan and Enterprise plan. Please refer to our pricing page for more information about our plans and features.", title = "Pro+ Plan", cta = "Read more", href = "https://coderabbit.ai/pricing", disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="shield-plus" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const GitLabBadge = ({tip = "This feature is available on GitLab.", title = "GitLab", cta, href, disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="gitlab" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="github" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

<GitHubBadge title="GitHub Cloud" tip="Triage is available on GitHub Cloud." /> <GitLabBadge title="GitLab Cloud" tip="Triage is available on GitLab Cloud." /> | <ProPlusPlanBadge tip="Triage is available to organizations with Pro+ entitlement." /> <OpenBetaBadge tip="Triage is in beta." />

## How priority is derived

Triage ranks pull requests by the work they need and the value of acting on them. The ranking also considers:

* Review state, including approvals, requested changes, unresolved discussions, and whether CodeRabbit has reviewed the latest reviewable commit
* Recent human and provider activity
* Risk, security findings, and the likely impact of the change
* The effort required to review or complete the pull request
* CodeRabbit analysis, including review guidance and change context
* Dependencies, stacked changes, and whether one pull request blocks or affects another

These signals produce a priority, a workflow state, and a recommended next action. The ranking is recalculated as the pull request changes, new reviews arrive, checks finish, or related work moves forward.

Checks, merge conflicts, draft or readiness state, and base-branch drift can change the shown workflow or next action. They do not by themselves raise or lower priority.

## Priority levels

Triage currently assigns three priority levels against absolute thresholds:

| Priority | Meaning                                                                                      |
| -------- | -------------------------------------------------------------------------------------------- |
| **P1**   | High-priority work that warrants prompt attention.                                           |
| **P2**   | Normal-priority work with a clear next step but less urgency or impact than P1 items.        |
| **P3**   | Lower-priority work that can generally wait behind more actionable or consequential changes. |

Priority does not change merely because other pull requests enter or leave the queue. It can change when new information arrives. Triage does not expose the internal numeric thresholds behind these levels.

### Close candidates

A close candidate is separate from the P1–P3 scale. It means the available evidence suggests that a pull request should be reviewed for closure, for example because it appears dormant, duplicated, or superseded and has no protected blocker that requires it to stay open.

The designation is conservative and does not close the pull request. A user chooses whether to close it, ignore the recommendation, restore it later, or report a false positive.

## Workflow and responsibility

Priority answers which pull requests deserve attention first. Workflow state answers what must happen next. Triage can distinguish work that needs an author update, human review, a maintainer decision, conflict or CI repair, merge action, monitoring, or closure review.

Responsibility is tracked separately from workflow, but cards do not currently display a responsible-role label. Instead, workflow tags such as **Needs human review** and **Needs author action** show who should act next.

Two pull requests with the same provider state can rank differently. For example, two open pull requests awaiting review may differ in risk, blocked downstream work, review effort, or recent activity.

## Reviewer suggestions

Triage can suggest reviewers from people and teams with evidence of fit for the change. Candidate sources include current or requested reviewers, CODEOWNERS, recent contributors, prior reviewers, and repository teams.

Fit reflects signals such as ownership, prior review activity, contribution history, and coverage of the affected code. Bots are excluded from the human reviewer candidate pool. Suggestions remain user-controlled: you can request, remove, or replace a reviewer where the provider supports the action.

## Freshness of review signals

Review-derived signals are useful only while they describe the current change. Blast radius, change type, issue severity, and security risk are displayed only when they cover the latest reviewable commit; if the author pushes a newer reviewable commit, these signals remain hidden until CodeRabbit analyzes the new version. Review effort, risk, and review guidance can persist across a push.

For the underlying review concepts, see [Estimated review effort](/pr-reviews/walkthroughs#estimated-review-effort) and [Git platform review metrics](/guides/dashboard-metrics). Triage uses these concepts as inputs without changing their definitions.

## What's next

<CardGroup cols={1}>
  <Card title="Triage overview" href="/triage" icon="list-filter" horizontal>
    Return to the Triage overview for built-in views, filters, card fields, and available actions.
  </Card>

  <Card title="PR Walkthroughs" href="/pr-reviews/walkthroughs" icon="list-tree" horizontal>
    Review the CodeRabbit analysis that supplies effort and other pull request signals.
  </Card>

  <Card title="Git platform review metrics" href="/guides/dashboard-metrics" icon="chart-no-axes-combined" horizontal>
    See how CodeRabbit defines review and delivery metrics across merged pull requests.
  </Card>
</CardGroup>