> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitor organization-wide pull request findings
> Track and analyze pull request findings across all your repositories from a central location in the Qodo portal.
export const AzureIcon = () => ;
BetaGitHubGitLabBitbucketAzure DevOps
Every time Qodo reviews a pull request, it generates findings: issues identified in the code such as bugs, cross-repo findings, rule violations, and requirement gaps. The Findings page in the Qodo portal tracks these centrally across all your repositories, giving team leads and engineering managers visibility beyond individual reviews.
In the Qodo portal, select **Findings** from the left navigation menu.
## Key metrics
At the top of the page, Qodo displays aggregated metrics for the last 30 days:
* **Total critical findings**: Total number of action-required findings identified across all pull requests.
* **Critical findings resolved %**: Percentage of action-required findings that were resolved before merge.
* **Average critical findings per PR**: Average number of action-required findings per reviewed pull request.
## How to interpret findings
Start with the analytics cards to get a picture of trends over the last 30 days, then use the findings table to drill down by repository, PR, action level, or category. Focus on:
* **Findings merged without resolution**, to identify where standards enforcement needs tightening.
* **Recurring findings across repositories**, to spot systemic issues that may warrant a new rule or team-wide guidance.
* **Resolved critical findings**, to validate that the review process is working as intended.
## Filtering and search
Use the filters to narrow findings by PR, Repository, Finding state, action level, category, and type. Use search to find findings from a specific pull request without navigating into the PR directly.
## Findings table
The Findings table lists all findings across your repositories. Each row includes:
| Column | Description |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Findings** | A short description of the finding. |
| **PR** | A link to the pull request where the finding was identified. |
| **Repository** | The repository where the finding was identified. |
| **State** | Current status of the finding. |
| **Action level** | Priority: Action Required, Remediation Recommended, or Other. |
| **Category** | Quality dimension: Correctness, Security, Reliability, Performance, Observability, Architecture, Testability, Quality, Accessibility, or Maintainability. |
| **Type** | Finding type: Bug, Cross-repo, Rule violation, or Requirement gap. |
| **PR author** | The author of the pull request where Qodo identified the finding. |
## Exporting findings
Click **Export CSV** in the top-right corner of the page to download the current findings as a CSV file. The exported data reflects the filters currently active on the page.
## Finding states
| State | Description |
| ------------- | -------------------------------------------------------------- |
| **Pending** | The PR is still open and the finding has not been addressed. |
| **Resolved** | The finding was resolved through code changes or a fix prompt. |
| **Ignored** | The developer merged the PR without resolving the finding. |
| **Dismissed** | The finding was closed without being resolved or fixed. |
## Finding details
Click any row to open a detail panel showing the full context of that finding: what the issue is, where it appears in the code, and why Qodo flagged it. Each finding is associated with a specific pull request, so you can see whether the issue was resolved before merge.
The detail panel includes:
* **Full description and code reference**: the exact location in the code where the issue was identified.
* **Evidence**: Qodo's reasoning for why this was flagged.
If the finding relates to a rule violation, the evidence section links directly to the specific rule in the [Rules page](/governance/rule-enforcement/generate-and-manage-rules).
## Best practices
* **Start with the big picture**: Check the analytics cards before drilling into individual findings, and filter the table by action level to focus on what matters most.
* **Look for patterns, not just volume**: The same finding type appearing across multiple repositories usually signals a systemic gap in team practice rather than an isolated issue.
* **Use findings to iterate on your [rules](/governance/rule-enforcement)**: Routinely ignored findings or a rising proportion of findings merged without resolution are a signal that your governance configuration needs adjustment. Refine the rule rather than accepting the noise.
## Next steps
* To see how findings appear to developers in individual pull requests, see [Anatomy of Qodo findings in a PR](/code-review/comment-anatomy).
* To act on recurring findings by creating or refining rules, see [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules).
* To understand how cross-repo findings are generated, see [Cross-repository code review](/governance/cross-repo-code-review).
## Key metrics
At the top of the page, Qodo displays aggregated metrics for the last 30 days:
* **Total critical findings**: Total number of action-required findings identified across all pull requests.
* **Critical findings resolved %**: Percentage of action-required findings that were resolved before merge.
* **Average critical findings per PR**: Average number of action-required findings per reviewed pull request.
## How to interpret findings
Start with the analytics cards to get a picture of trends over the last 30 days, then use the findings table to drill down by repository, PR, action level, or category. Focus on:
* **Findings merged without resolution**, to identify where standards enforcement needs tightening.
* **Recurring findings across repositories**, to spot systemic issues that may warrant a new rule or team-wide guidance.
* **Resolved critical findings**, to validate that the review process is working as intended.
## Filtering and search
Use the filters to narrow findings by PR, Repository, Finding state, action level, category, and type. Use search to find findings from a specific pull request without navigating into the PR directly.
## Findings table
The Findings table lists all findings across your repositories. Each row includes:
| Column | Description |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Findings** | A short description of the finding. |
| **PR** | A link to the pull request where the finding was identified. |
| **Repository** | The repository where the finding was identified. |
| **State** | Current status of the finding. |
| **Action level** | Priority: Action Required, Remediation Recommended, or Other. |
| **Category** | Quality dimension: Correctness, Security, Reliability, Performance, Observability, Architecture, Testability, Quality, Accessibility, or Maintainability. |
| **Type** | Finding type: Bug, Cross-repo, Rule violation, or Requirement gap. |
| **PR author** | The author of the pull request where Qodo identified the finding. |
## Exporting findings
Click **Export CSV** in the top-right corner of the page to download the current findings as a CSV file. The exported data reflects the filters currently active on the page.
## Finding states
| State | Description |
| ------------- | -------------------------------------------------------------- |
| **Pending** | The PR is still open and the finding has not been addressed. |
| **Resolved** | The finding was resolved through code changes or a fix prompt. |
| **Ignored** | The developer merged the PR without resolving the finding. |
| **Dismissed** | The finding was closed without being resolved or fixed. |
## Finding details
Click any row to open a detail panel showing the full context of that finding: what the issue is, where it appears in the code, and why Qodo flagged it. Each finding is associated with a specific pull request, so you can see whether the issue was resolved before merge.
The detail panel includes:
* **Full description and code reference**: the exact location in the code where the issue was identified.
* **Evidence**: Qodo's reasoning for why this was flagged.
If the finding relates to a rule violation, the evidence section links directly to the specific rule in the [Rules page](/governance/rule-enforcement/generate-and-manage-rules).
## Best practices
* **Start with the big picture**: Check the analytics cards before drilling into individual findings, and filter the table by action level to focus on what matters most.
* **Look for patterns, not just volume**: The same finding type appearing across multiple repositories usually signals a systemic gap in team practice rather than an isolated issue.
* **Use findings to iterate on your [rules](/governance/rule-enforcement)**: Routinely ignored findings or a rising proportion of findings merged without resolution are a signal that your governance configuration needs adjustment. Refine the rule rather than accepting the noise.
## Next steps
* To see how findings appear to developers in individual pull requests, see [Anatomy of Qodo findings in a PR](/code-review/comment-anatomy).
* To act on recurring findings by creating or refining rules, see [Generate and manage rules](/governance/rule-enforcement/generate-and-manage-rules).
* To understand how cross-repo findings are generated, see [Cross-repository code review](/governance/cross-repo-code-review).