Troubleshooting Triage

|

​

When Triage will not open

Triage names the specific requirement you are missing rather than showing a generic error. Match the message you see: A few of these messages name the feature Queue; they are about Triage. Two more, which are about your session rather than your organization:

• “Your session isn’t valid for this organization” — sign in again. If that does not help, your access to the organization may have been removed.
• “You don’t have access to Triage” — your account does not meet one of the requirements above. An organization admin can check the plan and your membership.

​

The queue is empty

An empty queue is usually correct. Triage tells you which kind of empty it is: If you expect pull requests that are not there, check the two scoping rules: Triage shows only repositories your signed-in GitHub account can access, and it excludes archived repositories.

​

A card looks out of date

Cards are Triage’s stored view of your pull requests, not a live provider query, so a card can lag GitHub briefly. Triage repairs this on its own:

• When cards render, Triage quietly re-reads live GitHub state for the rows on your screen and corrects them.
• Coming back to the tab triggers the same repair, at most once every ten minutes.

There is no continuous polling and no refresh button, and a repair that is skipped — because it is already running, or because too many have run recently — is silent. If a card’s state matters right now, open the check panel, which reads the provider when you open it, or open the pull request. A card also carries only one freshness timestamp for fields that arrive from different places at different times. A recent timestamp means something on the card was updated recently; it does not mean every field was.

​

A signal disappeared from a card

Signals that describe a specific reviewed commit are withdrawn when the author pushes a newer one, rather than shown against code they no longer describe. Change type, issue severity, blast radius, and security risk come back after CodeRabbit reviews the new commit. See Signal freshness.

​

An action is disabled or refused

​

Closing did not work

If the comment posted but the close failed, Triage says so and asks you to close again without a comment, so the note is not posted twice. Triage also remembers the exact comment for a short window and skips reposting an identical one, but that protection is best-effort: two tabs, two people, or a changed comment can still produce a second note.

​

Setting a priority failed

If the pull request was re-evaluated while your board was open, saving a priority fails and asks you to refresh and try again. That is deliberate — it stops you from overwriting a value you could not see. Reload and set it again. Remember that a manual priority cannot be cleared once set, and that setting one removes the safe-close recommendation from that card.

​

A Slack message did not arrive

Reviewer pings and digests need a chain of things to be true. Triage names the broken link:

​

Limits

​

What’s next