Skip to main content
Research Preview
Research Preview: PR Triage is set as Research Preview and is under active development. Functionality and results may evolve as we continue to improve the feature. Research Preview features are not covered by any SLA. We recommend reviewing and validating outputs before use, and advise against relying on them in business-critical workflows.
Code review can become a bottleneck when more pull requests are waiting for review than your teams have capacity to handle. Reviewers need to decide what to review first, identify pull requests that are blocking progress, and understand how related changes affect the work ahead. When pull requests are spread across repositories and Git providers, getting a complete view of the review backlog and organizing it for action is difficult. PR Triage in the Qodo portal brings your organization’s open pull requests across GitHub, GitLab, Bitbucket, and Azure DevOps into one shared queue. Your triage policies define the signals Qodo uses to prioritize this work, including SLA, priority, and Blast radius. Qodo combines triage signals with review findings, codebase relationships, and your organization’s policies to help you understand which pull requests need attention and why. Main PR Triage page

Access PR Triage in the Qodo portal

By default, PR Triage is accessible to Admins only. You can allow admins and team owners or all members to access PR Triage.

Set access to PR Triage

  1. Log in to the Qodo portal.
  2. Navigate to Account Management > Settings.
  3. Under Grant PR Triage access, select the access level:
    • Admins only.
    • Admins and team owners.
    • All members.
To open PR Triage, click PR Triage from the navigation panel.

Set your own triage policies

Click Policies on the main menu bar to configure how the queue decides priority, SLA, Blast radius, and Next action. Git organizations and repositories inherit triage policies from the workspace unless you override a setting. Use the Workspace, Git organization, and Repository tabs to choose where a setting applies. PR Triage Policies PR Triage applies a default triage policy when you first open it, so you can start prioritizing pull requests without configuring anything. Customize the policy to reflect how your organization manages review work, and apply different settings at the workspace, Git organization, or repository level. Select the arrow next to a setting to view and configure its parameters.
Set how long a requested review can wait before it is considered stale.
Define the conditions that determine whether a pull request is High or Medium priority. A pull request that does not meet any configured High or Medium priority rule is assigned Low priority.Priority: HighA pull request is assigned High priority when any enabled High priority rule applies.Priority: MediumA pull request is assigned Medium priority when it does not meet a High priority rule and any enabled Medium priority trigger applies.
Define what makes a pull request’s blast radius Medium or Large. Anything smaller is classified as Small.MediumReaches other repositories.LargeReaches many repositories, or blocks other pull requests.
Define when a quiet pull request stops competing for attention.
To apply your changes, click Save policy. You can select Restore Qodo defaults to reset the triage policy to Qodo’s default settings.

Manage review bottlenecks centrally

Once your policies are configured, use the shared queue to see open pull requests across your organization and investigate the work that needs attention.

Find where review work is accumulating

Open PR Triage to see your organization’s open pull requests in one shared queue. Use the queue to identify pull requests that need attention and filter the list to focus on specific states, review conditions, or types of work. The queue shows the signals that help you prioritize review work:
  • Priority: The priority level assigned according to your organization’s triage policies.
  • Blast radius: A measure of how broadly the pull request affects your codebase, showing the repositories reached and any critical repositories involved.
  • SLA: Where the requested review stands against its review deadline.
  • Time open: How long the pull request has been open.
  • Next action: The current state of the pull request and the action needed to move it forward, such as reviewing it, addressing findings, resolving checks, or merging.

Focus the queue on what matters to you

Use Filter on the menu bar to narrow the queue to the pull requests you want to review. Filter the queue by:
  • Priority: High, Medium, or Low.
  • State: Needs review, In review, Waiting for author, Blocked by checks, Conflict, Ready to merge, or Inactive.
  • Focus On: By default, Focus On is set to you and shows pull requests where you are the author or an assigned reviewer. Select another user to focus on their pull requests.
By default, pull requests are grouped by PR Stacks. Select No grouping to show pull requests individually. Combine filters to quickly find the pull requests that need attention. For example, set Focus On to yourself and Priority to High to see your highest-priority pull requests.

Explore PR stacks

When related pull requests are part of a PR stack, Qodo shows them together in the queue.
  • Expand a PR stack to see its related pull requests and understand how the changes are connected.
  • Select a pull request to investigate it in detail, including its relationships across the codebase.

Investigate a pull request

Select a pull request to open the pull request details pane. The pane gives you the signals and context behind the pull request’s position in the queue, so you can understand why it was prioritized and what may need attention. PR Triage Details Panel The pull request details pane brings together the relevant triage signals, findings, checks, and codebase relationships, with links to the corresponding details so you can investigate further without leaving the context of the pull request.

Understand why it ranks here

The Priority card shows the signals used to determine the pull request’s ranking and the source of each signal. Review:
  • Blast radius: How broadly the change reaches across your codebase, including critical or high-impact repositories.
  • SLA: The pull request’s position relative to its review deadline.
  • Findings: Findings that may affect the pull request’s priority, including action-required findings and violations of review standards.
  • Effort: The estimated effort required to address the pull request when available.
  • Reviewer: The reviewer assigned to the pull request if a reviewer was assigned.
  • Confidence: The confidence in the signals used to rank the pull request.
The card also shows when the ranking was last updated.

Review pull request status

The Status card shows the current review state, assigned reviewers, and review progress. When information from the Git provider is unavailable, the pane indicates which data is unknown, such as merge state, checks, or approvals.

Review findings and checks

The Findings card shows open findings identified during review, including their severity and links to the relevant findings. Click Open all findings for this pull request to view all findings for the pull request. The Checks card shows the current check status. When check results are unavailable, merge readiness is shown as unknown.

Explore cross-repository relationships

The Cross-repo map of the PR shows how the pull request’s repository relates to other repositories in your codebase. Use the map to understand which repositories are affected or connected to the change. Hover over a repository or relationship to see more detail. Open the full relationships graph when you need to investigate the complete set of relationships.

Take action

Once you understand the pull request and its context, you can:
  • Open the pull request in your Git provider.
  • Assign the work to yourself.
  • Continue investigating related pull requests in the PR stack.
  • Open the full relationships graph for deeper analysis.