ThisCalculator

Everyday

GitHub Code Quality: Find Enablement Changes by Event

Updated · Standard formula, shown below

GitHub Code Quality: Find Enablement Changes by Event

Yes, you can find enablement changes (when a feature or setting is turned on or off) on GitHub by event, but not through a single built-in search filter. Instead, you audit the audit log (for organization and enterprise accounts) or inspect commit and pull request history (for repository-level changes), then filter by the event type or the files changed. This article explains the practical ways to track enablement changes, what each method reveals, and how to choose the right one for your situation.

What Counts as an Enablement Change

An enablement change is any action that flips a setting from off to on (or on to off). On GitHub, these fall into three broad categories:

  • Repository settings: enabling or disabling branch protection, required status checks, merge strategies, or wiki and issue trackers.
  • Organization or enterprise policies: turning on SAML single sign-on, requiring two-factor authentication, enabling dependency graph, secret scanning, or code scanning.
  • Workflow or CI/CD changes: adding or removing a GitHub Actions workflow file, changing a scheduled trigger, or toggling a workflow’s enabled property.

Each type leaves a different trace, so the method you use depends on what you’re tracking.

The Audit Log: The Event Trail for Admins

For organization and enterprise accounts, the audit log is the authoritative source for enablement events. It records actions such as repo.create, repo.update, org.update_member, and crucially, repo.config.disable_anonymous_git_access or repo.config.enable_anonymous_git_access. You can filter by the action field and by the actor (who did it).

To access it:

  1. Go to your organization or enterprise settings.
  2. Click Audit log in the sidebar.
  3. Use the search bar with filters like action:repo.config.enable_* or actor:username.

For example, to find when branch protection was enabled on any repo, search action:branch_protection_rule.create. The audit log also exports to JSON or CSV, which makes it easy to script a search for multiple events.

Keep in mind: audit logs are only available for organization and enterprise accounts, not for personal repositories. Also, the log retains data for 90 days on free plans, 180 days on Team, and 365 days on Enterprise (or longer if you export).

Repository History: Tracking Config Files

For repository-level enablement changes, the most reliable method is to look at the commit history for configuration files. GitHub stores many settings in files like .github/workflows/*.yml (for Actions), .github/dependabot.yml (for Dependabot), or .github/codeql.yml (for CodeQL). When someone enables or disables a feature, they usually edit one of these files.

To find when a specific file changed:

  1. Open the repository on GitHub.
  2. Navigate to the file (e.g., .github/workflows/ci.yml).
  3. Click History (the clock icon) to see all commits that touched that file.
  4. Click any commit to see the exact diff.

This method works even for personal repositories, and it shows the exact change (e.g., a line changing from enabled: false to enabled: true). It also captures the commit message, which often explains why the change was made.

GitHub Actions: Event-Driven Workflow Toggles

If you’re using GitHub Actions, you can enable or disable a workflow from the Actions tab (the three-dot menu on a workflow run). That action is recorded in the audit log as workflow.enable or workflow.disable. But if you’re looking for changes to the workflow file itself (like adding a schedule trigger), that’s a commit event, not a separate enablement event.

To see when a workflow was last enabled or disabled via the UI, check the workflow’s run history. The audit log will show the exact timestamp and the actor. For file-based changes, use the file history method described above.

How to Choose the Right Method

Your choice depends on what you need to know:

  • Who changed a setting? Use the audit log (for org/enterprise) or the commit history (for repo files).
  • When did a setting change? Audit log gives exact timestamps; commit history shows commit times.
  • What exactly changed? Commit history shows the diff; audit log shows the action but not the file content.
  • Need to audit many repos? Use the audit log API to programmatically query events across all repos.

For example, if you suspect a teammate disabled required status checks, the audit log will show branch_protection_rule.destroy or branch_protection_rule.update. If you want to see the exact configuration change, you’d look at the commit that edited the branch protection settings (which are stored in the repository’s .github directory if using GitHub’s configuration-as-code).

Common Problems and Misconceptions

One common misconception is that the audit log records every setting change. In reality, it records actions that are part of GitHub’s internal event system, but some UI toggles (like enabling or disabling a wiki) may not appear as a clear

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.