Scheduled code scanning on GitHub now waits for a push or pull‑request event before it begins its weekly run on a repository. This shift eliminates the previous behavior where any unscheduled scan – such as the one‑time validation scan when default setup is enabled – marked a repository as active and triggered weekly scans even if no code changes occurred.
What changed in scheduling
The default setup still performs an immediate validation scan when you turn it on, populating findings right away. However, the recurring weekly scan is now gated by the presence of an analysis record that originates from a code change (push or PR). The system looks at analysis history rather than generic Git activity that predates scanning. Activity between code scanning and Code Quality remains shared, so both services respect the same trigger logic.
Why it matters to engineers and security teams
For AI, cloud, platform, DevOps, SRE, and security practitioners, the change reduces noise in scan reports and prevents unnecessary consumption of compute resources on dormant repositories. When you roll out a security configuration across many repos, you no longer risk inflating scan frequency for six months on repos that haven’t been touched. This makes budgeting for scan minutes and interpreting findings more predictable.
Operational implications
- Resource planning: Weekly scan slots will be allocated only to actively developed repos, freeing capacity for other workloads.
- Alert fatigue: Fewer unexpected findings from inactive code bases means security alerts stay relevant to current development work.
- Policy rollout: Large‑scale enablement of default setup no longer creates a temporary surge in scan activity; the initial validation scan is the only immediate impact.
- Cross‑service consistency: Since code scanning and Code Quality share the same activity model, teams can rely on a single expectation for both services.
What to watch next
Monitor the analysis history of your repositories to confirm that weekly scans only start after the first push or PR following default‑setup enablement. Verify that the expected reduction in scan frequency aligns with your cost and alerting models. The behavior is already live on GitHub Enterprise Cloud and will appear in GitHub Enterprise Server 3.24, so plan any version‑specific testing accordingly.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Expect a quieter scan schedule for repos without recent code changes, which simplifies capacity planning and reduces false‑positive noise. Adjust any monitoring dashboards that assume weekly scans start immediately after default setup; they should now reference the presence of a recent push or PR. No configuration changes are required, but updating internal documentation to reflect the new trigger condition will help teams avoid confusion during large‑scale security rollouts.