To track GitHub Code Quality configuration changes, search your organization’s audit log for repo.code_quality_enabled, repo.code_quality_disabled and repo.code_quality_updated. These events record that Code Quality was enabled, disabled or updated for a repository. Inspect the actor, repository and timestamp fields to identify who changed what and when.
Which audit-log events should you search for?
GitHub’s organization audit-log reference lists three events for Code Quality configuration changes:
As an Amazon Associate I earn from qualifying purchases.
| Event | GitHub’s description | What it tells you |
|---|---|---|
repo.code_quality_enabled |
Code Quality was enabled for a repository. | An enablement was recorded for that repository. |
repo.code_quality_disabled |
Code Quality was disabled for a repository. | A disablement was recorded for that repository. |
repo.code_quality_updated |
Code Quality was updated for a repository. | A configuration update was recorded, but the event description does not identify which setting changed. |
Use the event’s actual details when investigating. The documented fields include @timestamp, action, actor, actor_id, created_at, operation_type, org, repo, repo_id, repository, repository_id, user and user_id. Some event field sets also include public_repo or user_programmatic_access_name; do not assume every event contains every field. See GitHub’s organization audit-log event reference.
How to investigate a recorded change
- Search the organization audit log for the relevant event name:
repo.code_quality_enabled,repo.code_quality_disabledorrepo.code_quality_updated. - Open the matching entry and check its timestamp, actor and repository identifiers. Field names can vary among event records, so use the fields present in that entry.
- For an
updatedevent, treat it as evidence that a repository configuration update occurred; the documented description does not say which particular setting changed. - Check the organization’s Code Quality settings and enterprise policy to understand the intended scope of the change, especially if the event appears during a broader rollout.
Why a change may affect more than one repository
Code Quality can be enabled for an individual repository or through an organization-level Repository access setting. An organization can apply that setting to all repositories, a selected set, or repositories matching a filter. When a change affects repositories, GitHub presents a review dialog showing enabled and disabled repository totals and associated costs. Propagation begins immediately and can take several minutes in large organizations. The setting’s scope therefore matters when interpreting repository-level events in the context of a larger rollout. See GitHub’s Code Quality enablement instructions.
#1 Best Overall
Who can enable it?
Repository owners, organization owners and users with the repository admin role may enable Code Quality where the applicable plan and enterprise policies allow it. GitHub says Code Quality is available on GitHub Team or GitHub Enterprise Cloud, and GitHub Actions must be enabled. Enterprise owners control whether organizations can use Code Quality and can set repository administrator policy. See GitHub’s enterprise policy guidance.
What an organization-wide disablement means
Setting organization Repository access to “No repositories” turns off repositories that follow the organization default. It does not by itself turn off repositories that administrators explicitly enabled. Enterprise or organization policy enforcement is needed to prevent administrators from overriding the organization decision. This distinction can explain why an organization-level setting change does not have the same effect on every repository. See GitHub’s Code Quality disablement instructions.
Choose audit-log searches or webhooks based on the need
The audit log is useful when you need to investigate recorded organization events. For prompt notification and logging of selected events, GitHub notes that webhooks may be more efficient than audit-log searches or API polling. Confirm current webhook event coverage, payload fields and delivery behavior before building a Code Quality monitoring workflow around a specific payload; the audit-log documentation does not establish those details.
Keep scan behavior and billing separate from change tracking
Audit-log events record configuration changes; scan scheduling is a separate part of Code Quality operation. GitHub says the initial CodeQL scan runs on the default branch. Weekly scheduled scans start after a push or pull request triggers a scan, pause after 180 days without qualifying activity, and resume after another push- or pull-request-triggered scan. The 180-day threshold concerns scan scheduling, not audit-log event retention.
Disabling Code Quality stops future scans and the associated GitHub Actions minutes and AI credits, but license charges may continue for a period. GitHub also says a billing period’s charge can reflect the highest license use during that period, rather than the ending count. Disabling the feature therefore may free licenses for a later period without reducing the current period’s charge. These effects are relevant when reviewing a change, but they do not alter what the audit-log event means.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
