Skip to main content
|
Triage is available in beta to organizations with Pro+ entitlement on GitHub Cloud and GitLab Cloud.

Overview

Triage is CodeRabbit’s reviewer-first prioritization layer for agent-generated pull requests. It gives reviewers, maintainers, code owners, and team leads a self-updating, cross-repository queue that helps them decide which pull request to review next, how deeply to review it, and which pull requests may be safe to close. Find Triage in the sidebar under Review, or go directly to app.coderabbit.ai/triage.

Why Triage

Agent-generated pull request volume grows faster than human review capacity. Git providers organize PRs by repository and mechanical state, but they do not combine CodeRabbit’s analysis of value, review evidence, architecture, risk, reviewer expertise, and cross-pull-request relationships. Triage brings those signals into one queue so teams spend review time on work that needs human judgment.

Access and permissions

Members of an eligible CodeRabbit organization can view Triage without an active review seat. An active seat is required for actions that call the Git provider or use model capacity, such as starting a CodeRabbit review, closing an eligible pull request, or changing requested reviewers. Repairing a pull request does not require a seat. Triage follows the pull requests tracked for the organization. Provider permissions apply when an action changes a pull request. Triage refreshes provider state continuously, but a card can briefly lag GitHub or GitLab. Confirm the current provider state before closing or merging a pull request.

Built-in views

Triage includes four views for common review responsibilities: Safe to close is a recommendation. CodeRabbit does not automatically close these pull requests. You decide whether to close, ignore, or restore each candidate and can report a false positive.

Layout, grouping, and ordering

Switch between list and board layouts without changing the underlying queue. Triage saves layout and display preferences so each view can stay optimized for its purpose. Group the queue by review workflow, review guidance, risk, security risk, priority, repository, or author, or use no grouping. Order results by last activity, priority, created, pull request number, or title. The Safe to close view defaults to repository grouping and oldest activity first; the other built-in views prioritize higher-ranked work. Use filters to narrow the queue by:
  • Repository, author, or reviewer
  • Priority or review guidance
  • Risk or security risk
  • Review workflow or change type
Search matches pull request titles, owner/repository names, and pull request references such as #123.

Card information

Every card shows the repository, pull request number, author, title, and review workflow. Display settings can also surface the summary, last activity, change type, review guidance, risk, security risk, blast radius, review effort, issue severity, priority, and reviewers. Workflow tags indicate whether a pull request needs human review or author action. Cards can also show the number of downstream pull requests blocked by the change and whether the pull request is a close candidate. Review-derived signals appear only while they cover the latest reviewable commit.

Queue actions

Triage keeps common pull request actions next to the queue so you can move work forward without first finding it in the provider.

Open a pull request

Opening a card takes you to Change Stack when it is available for that pull request. Otherwise, Triage opens the pull request in GitHub or GitLab.

Start a CodeRabbit review

Request a CodeRabbit review for an eligible pull request and follow its state from the card while the review runs. See CodeRabbit’s pull request review workflow for the full review lifecycle.

Repair a pull request

Use repair actions to resolve merge conflicts or fix failing CI checks where the provider supports the action.

Close safely

Close an eligible pull request with an optional comment, ignore a close recommendation, restore an ignored recommendation, or report a false positive. Closure always requires a user action.

Manage reviewers

Request or remove reviewers, or suggest another reviewer where the provider and your permissions support the operation. Triage reviewer suggestions consider review history, repository ownership, and contribution context; see How prioritization works.

Provider limitations

  • GitHub: Triage can resolve merge conflicts and fix failing CI checks where those repair actions are available. Closing from Triage is supported for eligible pull requests on GitHub.com when the acting user has the required authorization.
  • GitLab: Triage can resolve merge conflicts where supported. Fixing CI, closing a merge request, and requesting or removing reviewers from Triage are not currently available.
  • Reviewers: Requesting and removing reviewers from Triage is currently available on GitHub only. Suggestions remain visible where generated; applying them still requires provider support and repository permissions.
  • Self-hosted deployments: Triage beta is not currently available for self-hosted GitHub or GitLab deployments.

What’s next

How prioritization works

Learn how Triage combines workflow, activity, risk, effort, and dependency context into priority and close recommendations.

Change Stack

Inspect a pull request as logical cohorts and layers after opening it from Triage.

PR Walkthroughs

Understand the CodeRabbit review signals that Triage can surface on pull request cards.