GitHub Adds Audit Logs for Code Quality Finding Dismissals and Reopenings

What changed​

GitHub announced on October 13, 2026 that organization and enterprise audit logs now record manual dismissals and reopenings of Code Quality findings. Two new events cover the actions:

• repo.code_quality_findings_dismissed records the dismissal of one or more findings.
• repo.code_quality_findings_reopened records the reopening of one or more findings.

According to GitHub's changelog, each event includes:

• who made the request
• when it happened
• the repository and the rule
• the identifiers and count of the affected findings

The findings can sit in a repository's default-branch backlog or in pull requests.

Availability and setup​

• For repositories with Code Quality enabled, no extra setup is needed.
• You need access to the organization audit log or the enterprise audit log. Filter by the two action names.
• On GitHub Enterprise Cloud, you can also retrieve the events through the audit log API.
• The feature is generally available on GitHub Team and GitHub Enterprise Cloud, including enterprises with data residency.
• It is not available on GitHub Enterprise Server.

I could not confirm API endpoints, token permissions or the exact field schema for these events. The changelog doesn't specify them, and GitHub's organization audit-log reference page did not yet list the new event names when I checked. Test your queries against real events before building automation on them.

Why a dismissal deserves a paper trail​

A dismissal is not a fix. GitHub's documentation gives examples of reasons to dismiss a finding. The code might be legacy and no longer maintained, the finding might be a known exception to team standards, or it might be a false positive that poses no real quality risk. Each of those is a judgment call.

Dismissals also affect the numbers people watch. GitHub's tutorial says that to improve a maintainability or reliability rating, you must resolve (fix or dismiss) all findings at the highest severity level for that metric. A dismissal can therefore improve a score without any code changing. On pull requests, administrators can set quality gates that block merges based on finding severity. Dismissing a finding there can clear the path to a merge.

The dismissals themselves are easy to do. GitHub's April 2026 update added the ability to select multiple findings and dismiss or reopen them in bulk from the rule page. That is why the new events record a count and a list of identifiers, not just a single finding.

What the audit trail does and doesn't tell you​

The events answer who, when, where, which rule and how many. The changelog doesn't mention a field for the reason behind a dismissal. GitHub's pull request guidance says you can dismiss a finding and provide a reason, but I can't say whether that reason appears in the audit event. Check a sample event before you rely on it.

The changelog also doesn't claim any approval workflow, policy enforcement, notifications or new retention rules. This is a record, not a gate.

GitHub's organization dashboard documentation already shows a dismissed count per repository over a chosen period. It also cautions that the dashboard tracks the total count of open findings, not individual findings being opened or fixed. That text comes from a separate search result; the audit events fill a different need. The dashboard shows how many findings were dismissed, and the audit log shows who did it.

How this fits with earlier audit coverage​

An August 20, 2026 GitHub changelog added repo.code_quality_enabled, repo.code_quality_disabled and repo.code_quality_updated. Those track configuration changes. With the October events, an admin can line up when Code Quality was switched on, reconfigured or turned off for a repository against who was triaging its findings.

GitHub's code scanning already had a comparable pattern. A December 2024 changelog described audit events for code scanning alerts being created, fixed, dismissed or reopened. Code Quality's events are separate actions with their own names, so don't assume they share fields with the code scanning events.

A practical review routine​

1. Confirm Code Quality is enabled on the repositories you care about.
2. Open the organization or enterprise audit log.
3. Search for repo.code_quality_findings_dismissed and repo.code_quality_findings_reopened.
4. Look at the actor, timestamp, repository, rule, finding identifiers and count on each event.
5. Look for patterns. Bulk dismissals of high-severity findings, dismissals just before a release, and a finding that keeps being dismissed and reopened are all worth a closer look.
6. On Enterprise Cloud, consider pulling the events through the audit log API once you've verified the fields.

Bottom line​

This is an incremental but useful governance feature. It makes one of the easiest actions in Code Quality, quietly clearing a finding, something you can review afterward. It won't tell you whether a dismissal was justified, but it will tell you who to ask.