Triage rules

| Triage rules act on pull requests that match conditions you choose. Use them to merge low-risk changes, close stale pull requests after notice, repair CI and review feedback, or remind authors and reviewers in Slack. Open Triage settings in the organization you want to configure. Rules belong to that organization and apply to the repositories you select. Rules automate actions. Priority Guidance controls ranking separately: a rule that matches P0 or P1 does not assign that priority.

​

Who can manage rules

Rules are available to eligible organizations on the Team plan or higher on CodeRabbit Cloud. Members can view rule settings without an active Review seat; opening the Triage queue has separate access requirements. Members can draft a GitHub action, but an organization administrator must save and enable it. A rule containing both a GitHub action and a Slack action needs administrator access. People and team selectors also require administrator access; existing selections are preserved when unavailable. Automated GitHub actions use the organization’s CodeRabbit integration. Its repository permissions and GitHub branch policies still apply. They do not borrow the permissions of the person viewing the rule. Manual actions from a Triage card continue to use your own GitHub authorization.

​

Start with a template

Choose Use template, or create a custom rule. Templates provide editable starting conditions; choosing one does not enable automation.

​

Configure a rule

​

Repositories

Give the rule a name and choose All or Selected repositories. All includes future repositories in the organization; Selected limits the rule to the repositories you add. Add filters to a repository card to narrow its matches:

• File path: use glob patterns such as src/** or !dist/**. Leave the filter blank to allow all paths.
• PR labels: choose has any of, has all of, or has none of, then select labels from that repository.

A file-path filter matches when at least one changed path passes the patterns. It does not guarantee that the PR changes only those files. Repository filters and the rule’s triggers must both match. If CodeRabbit cannot establish the current changed files or labels, it does not treat missing evidence as a match.

​

Triggers

Use Add trigger for an alternative matching group. Any trigger can match; conditions joined by and within a trigger must all match. Workflow conditions use the rule creator’s Triage perspective. Viewing or editing the rule as someone else does not change that perspective. Conditions use current evidence about the pull request. Missing, incomplete, or stale evidence stays unknown; it cannot authorize an action. For example, pushing a new commit can make a risk condition wait for an updated review.

​

Actions

Choose one Git-provider action and optionally one Slack action, or use Slack on its own. A single rule cannot combine merge, close, and Auto-fix actions with one another.

​

Merge pull request

Choose Squash, Merge commit, or Rebase. The rule merges only after the required checks and reviews pass and GitHub permits the merge. Low risk and low effort do not override branch protection, missing permissions, or a changed commit. For branches that require a merge queue, CodeRabbit submits the pull request to GitHub’s queue. GitHub controls the queue’s ordering, checks, and merge method. A queued pull request is not yet merged.

​

Close pull request

New close actions post a notice and wait 24 hours before closing. The wait starts when the notice has been posted successfully. Before closing, CodeRabbit checks that the rule still applies and that the pull request has not changed in a way that prevents the close. New relevant activity cancels the pending close. Use Close stale PRs for the 30-day inactivity condition, or choose your own conditions. A Close candidates recommendation alone never authorizes closure; an enabled close rule or a separately confirmed action does.

​

Auto-fix PRs

Auto-fix PRs, also called Bring PR to ready, asks the Coding Agent to repair an inactive pull request. It can fix failed CI checks and address CodeRabbit findings and human feedback. It does not merge the pull request or replace required human approval. Select at least one kind of issue to address. The agent replies to human feedback and leaves human threads open for review. A run can finish ready, awaiting human review, with nothing actionable, or blocked; starting a run does not guarantee a repair.

​

What starts the inactivity clock

Auto-fix waits after the latest relevant PR activity received by CodeRabbit: code changes, feedback, reviews, or CI updates. Relevant bot activity resets the wait too. Title, label, and assignee changes do not reset it. This is different from the Last activity trigger, which measures human activity. Save the rule with Save rule, then enable it. Automatic repairs require new relevant activity after the rule is enabled. Editing or resuming the rule starts a new activity boundary. A PR that was already inactive does not become eligible merely because you enabled the rule or opened Triage. For example, with a four-hour wait, a PR that receives a CI update at 10:00 after you enable the rule can become due at 14:00. A review comment at 13:00 moves that time to 17:00. A PR with no relevant activity after enablement remains untouched. Auto-fix has no Review matches or existing-PR selection step. It watches for new relevant activity after enablement rather than running through an existing backlog. Runs may wait for available repair capacity after they become due.

​

Send Slack reminders

The Send reminder action targets the PR author and reviewers. Choose a delivery time and timezone. New Slack actions default to 6:30 PM, America/Los_Angeles, with a 24-hour cooldown and respect for quiet hours. The timezone follows its local daylight-saving rules. Existing rules without a delivery schedule keep their match-triggered behavior. Choose Set delivery time to add a schedule. Delivery requires a connected Slack workspace, resolved GitHub-to-Slack identities, and recipients whose notification settings allow it. Missing or ambiguous identity mappings do not result in a guessed recipient. Quiet hours and cooldowns can delay delivery. For automatically enrolled PRs, reminders can repeat while the PR remains eligible and the cooldown has elapsed after the previous completed execution. A one-time selection of existing PRs does not enroll them for recurring reminders. Slack can accompany a merge or close action, but its delivery does not prove the GitHub action succeeded. When paired with Auto-fix, Slack provides feedback from the repair run. For personal digests, reviewer pings, or following a PR in a chosen channel, see Triage in Slack.

​

Preview and enable

Merge, close, and Slack rules use Review matches before confirmation:

1. Configure the rule and select Review matches. Saving alone does not enable it.
2. Inspect the matching PRs and their eligibility explanations. A condition match can still be blocked by missing evidence, permissions, or action requirements.
3. Choose whether to enable automation for future matching PRs. To act on existing matches, select the eligible PRs and explicitly confirm that selection. A selection is limited to 50 PRs.
4. Review progress and per-PR outcomes. If the PR or rule changes before execution, CodeRabbit rechecks it and can refuse the action rather than substitute another PR.

One-time confirmed merge, close, or Slack actions can run while the saved rule remains disabled. Enabling future automation and confirming actions on existing PRs are separate choices. For these rules, PRs already matching when monitoring starts are not automatically acted on. Newly opened PRs can qualify after activation; older PRs need an observed change from not matching to matching, or explicit selection and confirmation. Unknown evidence does not count as a confirmed failure to match that authorizes a later action. Auto-fix uses its separate save-and-enable flow.

​

Manage rules and inspect activity

Use the rule list to edit, enable, pause, resume, or delete a rule. Editing creates a new version and cancels pending actions from the previous version. An active rule stays active after an edit; a disabled rule stays disabled. Pausing, deleting, or cancelling stops pending work. Actions already in progress may still finish. These controls do not undo a completed action or an action already accepted by GitHub. Deleting a rule retains its past runs and history. Before resuming a rule paused after access denial or repeated failures, check the integration permissions and activity history. Use Activity and a rule’s action history to inspect runs and outcomes. Administrators can inspect run activity; members’ rule information is restricted by their access. A queued or in-progress entry is not a success confirmation. An uncertain result means CodeRabbit cannot yet establish what the provider did; it does not blindly repeat that action. Incompatible rules, such as overlapping merge and close rules or different merge methods for the same matches, can block saving or activation. Narrow their scopes or conditions, or pause the conflicting rule. If CodeRabbit cannot prove the rules are separate, it can require the conflict to be resolved before continuing.

​

What’s next