When a development team uses automated code analysis, not every finding results in a code change. Some findings are fixed immediately, while others are dismissed because they are irrelevant, already addressed, or accepted as technical debt. The challenge is knowing who made that decision and when it happened, especially when multiple developers maintain the same repositories.
GitHub has introduced two new audit log events for GitHub Code Quality that record when findings are manually dismissed or reopened. The change gives organization owners, security teams, and engineering managers a centralized way to review these decisions without relying entirely on repository activity or individual team members' recollections.
The improvement is particularly useful for teams that manage code quality across multiple repositories and need a reliable history of decisions affecting maintainability and reliability.
In this article, we will examine the new audit events, explain how to find them, demonstrate how to retrieve audit records using the GitHub CLI, and discuss practical ways to incorporate the information into an engineering team's review process.
What Is GitHub Code Quality?
GitHub Code Quality helps developers identify maintainability and reliability problems in their code. It combines CodeQL-based analysis with AI-assisted detection to identify issues that may make applications harder to maintain or less reliable.
Depending on the finding and development workflow, a developer may resolve the issue, review an automated fix, or dismiss the finding when it does not require further action.
For example, consider a C# application containing a method with unnecessarily complicated conditional logic. A code-quality finding might recommend simplifying that method. A developer could implement the change, verify the behavior with tests, and remove the underlying issue.
However, some findings require a different decision. A team might determine that a suggested change is not appropriate for the current implementation. That decision should be deliberate, particularly when it affects a repository's quality backlog.
GitHub's new audit events help administrators track these manual dismissals and subsequent reopenings.
What Has Changed in GitHub Audit Logs?
GitHub introduced two events that record manual dismissal and reopening activity for Code Quality findings.
Audit event | Purpose | Information recorded |
|---|
repo.code_quality_findings_dismissed
| Records the dismissal of one or more findings | Actor, timestamp, repository, rule, affected finding identifiers, and count |
repo.code_quality_findings_reopened
| Records the reopening of one or more findings | Actor, timestamp, repository, rule, affected finding identifiers, and count |
These events make it easier to investigate questions such as:
Who dismissed a particular group of findings?
When were the findings dismissed?
Which repository and analysis rule were involved?
How many findings were affected?
Who reopened findings that had previously been dismissed?
The events are available in organization and enterprise audit logs.
On GitHub Enterprise Cloud, administrators can also retrieve these events through the audit log API. The feature is generally available on GitHub Team and GitHub Enterprise Cloud, including Enterprise Cloud with data residency. It is not available on GitHub Enterprise Server.
The important distinction is that these events record decisions about findings. They do not automatically approve dismissals, enforce quality policies, or guarantee that the underlying code has been corrected.
Why Dismissal and Reopening History Matters
A dismissed finding is not necessarily a resolved finding. It represents a decision that the team should be able to review when necessary.
Without centralized audit records, investigating a dismissal may require checking individual repository activity, reviewing team discussions, or asking the developer who performed the action.
The new events provide a more direct starting point for that investigation.
Better Accountability
Consider a team that maintains several .NET services. One developer dismisses a finding in a payment-processing repository, while another developer later determines that the issue deserves attention.
The audit log helps administrators establish who performed each action and when it occurred. This creates a clearer history for technical reviews and internal investigations.
Easier Quality Reviews
Engineering managers can use dismissal and reopening records to identify recurring patterns. For example, repeated dismissals involving the same rule may indicate that the rule needs review, the development team needs additional guidance, or the code requires a broader architectural improvement.
The audit event alone does not establish why a decision was made. Teams should retain their own review notes and supporting evidence where a rationale is required.
Improved Governance
Organizations with formal engineering standards may need to demonstrate that quality-related decisions are traceable.
Centralized audit events help establish a record of activity. However, teams should not treat an audit record as proof that a finding was correctly dismissed or that a required approval process was followed.
How to Find Code Quality Dismissal and Reopening Events
You can investigate these events directly through the GitHub organization or enterprise audit log.
Step 1: Open the Appropriate Audit Log
Sign in to GitHub with an account that has permission to access the relevant organization or enterprise audit log.
Choose the organization or enterprise whose activity you need to investigate.
Step 2: Filter for the Relevant Event
Search for the dismissal event:
repo.code_quality_findings_dismissed
To investigate reopening activity, use:
repo.code_quality_findings_reopened
These are the exact event action names introduced for this feature.
Filtering by the action name helps narrow the audit records to the activity you want to investigate, rather than requiring you to review unrelated administrative and repository events.
Step 3: Review the Event Details
Inspect the available record fields to identify the actor, timestamp, repository, rule, and affected findings.
For example, suppose a review identifies an unexpected dismissal in a repository named order-service.
The investigation should establish:
Which account performed the dismissal.
When the event occurred.
Which quality rule was associated with the findings.
Which finding identifiers were affected.
Whether a subsequent reopening event exists.
This sequence gives reviewers a factual starting point for investigating the decision.
Step 4: Document the Investigation
If the dismissal requires further review, record the finding identifiers, the relevant audit events, the investigation outcome, and any corrective action.
Do not assume that the event itself contains the full business justification for a dismissal. Where a decision needs approval or a documented rationale, retain that information in the team's established review process.
Retrieving Audit Events with the GitHub CLI
For repeatable investigations, administrators can retrieve audit records programmatically instead of relying exclusively on the web interface.
The following example uses the GitHub CLI to query an organization's audit log for dismissal events. Replace YOUR_ORGANIZATION with the organization login and ensure that the authenticated account has the necessary permissions.
gh api --paginate "/orgs/YOUR_ORGANIZATION/audit-log" \
-f phrase="action:repo.code_quality_findings_dismissed"
The command requests audit records matching the dismissal action. The --paginate option allows the CLI to retrieve subsequent pages when the API returns paginated results.
To investigate reopened findings, change the action filter:
gh api --paginate "/orgs/YOUR_ORGANIZATION/audit-log" \
-f phrase="action:repo.code_quality_findings_reopened"
Important Implementation Considerations
The examples demonstrate how to filter by event type. They do not implement a complete audit reporting system.
For production use, consider the following:
Permissions: Use an appropriately authorized account or automation identity.
Time ranges: Narrow queries to the relevant investigation period when supported by the audit log query syntax.
Pagination: Ensure that every returned page is processed.
Error handling: Handle authentication failures, permission errors, rate limits, and transient API failures.
Data handling: Protect exported audit records because they may contain internal repository and user information.
Verification: Inspect actual returned records before building automation around individual fields.
Enterprise administrators should also verify the supported API scope and query syntax for their account configuration.
Best Practices for Managing Code Quality Decisions
1. Establish a Consistent Dismissal Policy
Define when developers may dismiss findings and when additional review is required.
For example, a team might allow routine dismissals for demonstrably irrelevant findings while requiring a documented review for findings involving critical application paths.
The exact policy should reflect the application's risk profile.
2. Review Repeated Dismissals
Repeated dismissals associated with a particular rule deserve investigation. They may indicate noisy findings, misunderstandings about the rule, or recurring technical debt.
Use audit records to identify the activity, then inspect the affected code and review the engineering context before deciding what to change.
3. Treat Reopening as a Signal for Investigation
A reopened finding may indicate that an earlier decision needs reconsideration. Review the associated code and determine whether a fix, additional testing, or a policy adjustment is necessary.
Do not assume that every reopening represents a confirmed defect. The event records an action, not the final technical conclusion.
4. Automate Reporting Carefully
Organizations can use the audit log API to collect relevant events for internal reporting or investigations.
If you build a reporting pipeline, make it resilient to pagination, API failures, duplicate processing, and changes in the volume of events. Store only the information required for the reporting purpose and apply appropriate access controls.
5. Keep Audit Records Separate From Quality Metrics
A high number of dismissals does not automatically mean that a team has poor code quality. Likewise, a low number does not prove that the codebase is healthy.
Combine audit activity with findings, remediation progress, test results, and engineering review to obtain a more meaningful picture of repository health.
Advantages and Disadvantages
Advantages
Centralized visibility: Organization and enterprise administrators can investigate dismissal and reopening activity from audit logs.
Clearer accountability: Records identify the actor and time associated with a decision.
Programmatic access: Enterprise Cloud users can retrieve the events through the audit log API, supporting repeatable investigations and reporting.
Better governance: The records help teams review quality-related decisions across repositories.
Disadvantages
No automatic enforcement: Logging an action does not prevent inappropriate dismissals or require approval.
Limited context: An audit event is not a substitute for a detailed technical explanation or documented risk assessment.
Access requirements: Users need the appropriate audit log permissions, and availability differs between GitHub hosting plans.
Additional operational work: Teams that want centralized reports must build and maintain the collection, storage, and analysis process.
Common Mistakes and Troubleshooting
No Events Appear in the Search
Confirm that you selected the correct organization or enterprise audit log and used the exact event action name. Also check the relevant time range and your account permissions.
If no matching action occurred during the selected period, an empty result is expected.
The Audit Record Does Not Explain Why a Finding Was Dismissed
The documented event fields identify the actor, time, repository, rule, and affected findings. Do not assume that every event includes a complete justification.
Review the finding and any associated team documentation to establish the reasoning behind the decision.
API Requests Return Permission Errors
Check the authentication method, organization access, and permissions required to read audit logs. Verify that the account is authorized for the relevant audit scope before changing the query.
A Report Shows More Dismissals Than Expected
Check whether your reporting process handles pagination and repeated retrieval correctly. Also confirm whether your reporting window overlaps with previously processed events.
Use stable identifiers and timestamps where available to help prevent duplicate counting.
Summary
GitHub's new Code Quality dismissal and reopening audit events make quality-related decisions easier to investigate and track. The events repo.code_quality_findings_dismissed and repo.code_quality_findings_reopened provide details about who performed an action, when it happened, which repository and rule were involved, and which findings were affected.
The improvement is useful for engineering teams that need stronger accountability, repeatable investigations, and better visibility into code-quality decisions. Administrators can filter the organization or enterprise audit log directly, while GitHub Enterprise Cloud users can also retrieve the events programmatically.
For the best results, combine these records with a clear dismissal policy, technical review, and appropriate documentation. Audit logs provide an important history of actions, but maintaining reliable code quality still depends on developers investigating findings, validating fixes, and making informed engineering decisions.
Join the conversation! Your thoughts help the community grow.