The card
The unit of work in Triage is a card: one open pull request, identified by its organization, repository, and pull request number. Everything in Triage is a statement about a card — its priority, its next action, its risk, who should look at it, and what you can do to it without leaving the queue. A card is a projection, not a live window onto your provider. CodeRabbit maintains it from provider events and from its own review results, so it stays current without polling GitHub on every page load. Two consequences are worth knowing before you act on one:- A card can lag the provider by a short interval, and a recent timestamp on a card does not prove that every field on it was refreshed at the same moment. Different signals arrive from different sources.
- Signals derived from a CodeRabbit review describe the commit that was reviewed. When an author pushes a newer one, some of those signals are withdrawn rather than shown against code they no longer describe. See Signal freshness.
When a decision is expensive to get wrong — closing someone else’s work, or merging — open the pull request and confirm the current state before you act.
Availability
If Triage does not open for you, the page tells you which of these is missing — see Troubleshooting Triage.
Triage shows only the repositories you can see. Membership in the CodeRabbit organization is not enough on its own: the queue is scoped to the repositories your signed-in GitHub account can access, and archived repositories are excluded.
Viewing and acting
Any member of an eligible organization can open Triage and read the queue without a Review seat. Reading includes every view, filter, grouping, and card signal. Actions that write to your Git provider or spend model capacity require an active Review seat:
Provider-writing actions additionally run as you, using your own GitHub authorization — Triage never acts as a shared bot identity for them. An action you are not permitted to perform in GitHub is refused in Triage too. See Seat assignment for how seats are granted.
Use Follow on a tracked, open pull request card to select a Slack channel or direct-message group and receive pull request activity in a dedicated thread. The direct-message option preselects you, and the picker lists recently used, accessible channels before you search. For the shared destination, identity-linking, event-preference, and autofix mechanics, see Slack and Discord threads.
Working the queue
The first time through, this is the whole loop:1
Start where you are needed
You land on Requires my action — the pull requests you authored plus the ones you are reviewing, ranked. If you would rather see everything, switch to All PRs in the left rail.
2
Read down, not across
The order is the recommendation. Each card names its priority, the one thing that has to happen next, and a line explaining why it is ranked where it is.
3
Act from the card
Open it in Change Stack to review, or take the next action directly — start a CodeRabbit review, repair failing CI, find a reviewer, close it. See Actions on a pull request.
4
Narrow it once, then keep it
When you find a slice you keep coming back to — one repository, one risk level, work waiting on you — save the view rather than rebuilding the filters each morning.
How this section is organized
What’s next
Cards and signals
Read every field on a card, from its next action and review state down to blast radius and review effort.
Change Stack
Inspect a pull request as logical cohorts and layers after opening it from Triage.
How Triage prioritizes
Understand the evidence behind a priority, and override it when you know better.
