CodeQL Default Setup Enabled, but No Weekly Scans? Here’s the Trigger
CodeQL default setup went on across the whole organization, and every first scan passed. Why have some repositories not scanned again since?
- A successful initial analysis does not by itself activate weekly scans.
- A push or PR must trigger analysis after default setup has been enabled.
- Organizations can separately enable scans every 30 days for inactive repositories.
A first result does not promise a scan next week
If a repository has supported code and its initial analysis succeeds, the absence of a weekly run can still be expected. Under GitHub's October 1 change, weekly scanning waits for a push or pull request to trigger analysis after default setup is enabled.
This matters during bulk rollout. Applying a security configuration can produce an initial result without treating every dormant repository as active. Commit history from before scanning was enabled does not satisfy that condition.
The announcement covers weekly scans for code scanning default setup and GitHub Code Quality, which share the activity determination. It applies on Enterprise Cloud, with Enterprise Server 3.24 support planned. It is not a new rule for every manually authored scheduled workflow.
Look for qualifying analysis, not merely a recent commit
The default-setup reference lists pushes to the default or protected branches, and PR creation or commits targeting those branches, excluding PRs from forks. Weekly scans run when a push or PR has triggered analysis in the preceding 180 days.
| Event | Counts toward weekly-scan activity? |
|---|---|
| Initial analysis after enablement | No. |
| Analysis after configuration or language changes | No. |
| A scheduled scan | No. |
| A push or PR triggers default-setup analysis after enablement | Yes. |
Scheduled execution does not keep renewing the activity window by itself. The organization settings guide explicitly excludes initial, configuration, language-change and scheduled scans from activity.
Inactive repositories have a separate 30-day option
A repository can remain useful even when nobody is changing it. Organization owners can enable recurring scans for such repositories through Settings → Advanced Security → Global settings. Select the option to keep scanning inactive repositories every 30 days.
That period is fixed. The option does not let you pick a weekly or custom interval. If you need to own the analysis schedule, advanced setup provides control through a workflow and its triggers.
For a deliberately quiet repository, decide the scanning policy before manufacturing commits to keep a weekly schedule alive. Development-triggered scanning and recurring checks of inactive code serve different operational needs.
Enabled configuration is not proof of successful analysis
Inactivity is not the only reason scans stop. The configuration guide explains that default setup can remain enabled after analysis fails for every supported language, without continuing to run scans. That calls for fixing analysis, not merely waiting for the schedule.
- Confirm whether the repository uses default setup or a workflow you maintain.
- Inspect the initial result and any language-analysis failures.
- Find push- or PR-triggered analysis after enablement.
- For intentionally inactive repositories, inspect the organization's 30-day scanning option.
View CodeQL configuration exposes the configured setup, while the tool status page provides scan timestamps. Once initial analysis is healthy, the useful question is whether qualifying analysis has activated the weekly schedule. If the repository is meant to remain inactive, choose the recurring policy that fits that state.