Enabling code scanning no longer starts weekly scans on its own

A rollout is not the same as recurring coverage

When you apply a security configuration to a dormant repository, enabling code scanning default setup still runs an initial validation scan and populates findings. What it no longer does on its own is start weekly scheduled scanning. GitHub's October 1 announcement says that now requires a push or pull request to trigger an analysis. The rule also covers GitHub Code Quality's weekly scans. [1]

Previously, any unscheduled scan could count as recent activity, including enablement validation and scans caused by a change in detected languages. A rollout across dormant repositories could therefore make them look active for another six months and trigger unexpected weekly scans. GitHub now bases that activity decision on push- or pull-request-triggered analysis, rather than treating every scan as development activity. [1]

GitHub says no configuration change is needed for this behavior change. For maintainers of repositories edited by agents as well as people, the practical distinction is the same: the enabling action and the development-triggered analysis are separate evidence. Neither the repository's last commit before enablement nor a PR without evidence of an analysis establishes that weekly scanning has started. [1]

Inspect the analysis, not just the enabled setting

Use this read-only inspection sequence before diagnosing a quiet repository. It combines the announced scheduling rule with GitHub's documented status-page capabilities; it is not a vendor acceptance test. It concerns default setup and Code Quality, not every advanced setup or custom schedule. [1][2][3]

• 1. Confirm the environment and setup. Establish whether the repository uses default setup and whether cloud or server documentation applies. GitHub documents tool-status access for users with write access; if you cannot inspect it, ask an authorized maintainer for the relevant records rather than treating inaccessibility as an empty history. [1][3]
• 2. Open Security and quality → Code scanning → Tool status. Select CodeQL or the relevant tool, then the appropriate entry under Setup types and the configuration under Configurations. Do not use a recent result from a different setup as evidence for this one. [3]
• 3. Read the scan timestamps, language/file coverage and analysis errors together. GitHub documents timestamps and percentage of files scanned; the tool status page shows integrated-tool coverage by language and configuration-specific run information and errors. An enabled setting alone does not demonstrate a successful analysis. [2][3]
• 4. Establish the trigger where the available evidence permits. Separate enablement validation and language-detection analyses from a push/PR-triggered analysis after scanning was enabled. Check corresponding run or event details where available. The cited status-page documentation does not promise an event-origin field for every historical run; if you cannot establish the trigger, report it as unconfirmed. [1][3]
• 5. Check what happened afterward. A confirmed qualifying analysis supplies the weekly start condition; subsequent timestamps and errors are needed to assess later runs. Keep Code Quality activity in view because GitHub says activity remains shared between the two services. Do not infer undocumented cross-service behavior. [1][2][3]

This distinction also avoids misclassifying a configuration failure as inactivity. GitHub's default-setup documentation says that if analyses fail for every CodeQL-supported language, default setup remains enabled but does not run scans until a supported language is added or setup is manually reconfigured, and analysis of a supported language succeeds. An observed failure calls for troubleshooting, not an assurance that silence is expected. Inspect first; any setting change is a separate authorized action. [2]

A completed example: validation without a qualifying analysis

Hypothetical example—not an observed repository: a maintainer enables default setup on a dormant Enterprise Cloud repository. Assume initial validation succeeds and produces findings. The available history is complete for the period since enablement and contains only that validation, with no later push/PR-triggered analysis and no qualifying activity from Code Quality.

The maintainer's conclusion is: initial analysis occurred, but enablement alone has not established the weekly start condition. Under the announced rule, the absence of weekly scans is expected in this validation-only scenario; it is not, by itself, evidence that rollout failed. The findings are evidence from the initial analysis, not evidence of continuing scans or a guarantee that the repository is safe. [1]

Now change one assumption: a genuine maintenance pull request triggers an analysis after enablement, and the record confirms that trigger. The documented weekly start condition is met. The maintainer still checks subsequent scan timestamps and errors before reporting that later scans completed. There is no reason to push a dummy commit merely to manufacture activity. [1][2][3]

If the history is incomplete or the trigger cannot be confirmed, neither conclusion is supported. The finished report is instead: initial validation is recorded, but the evidence available does not establish whether qualifying analysis occurred; continuing weekly coverage is unconfirmed. Obtain the missing run or event records before calling the deployment broken or the repository covered.

Starting the schedule does not guarantee indefinite scanning

The start condition and the later inactivity condition answer different questions. GitHub's default-setup documentation says the weekly schedule is disabled after six months without pushes or pull requests, and notes a separate option for organization owners to enable monthly scans of inactive repositories. That option is not a new weekly guarantee, and this briefing does not recommend changing it. One qualifying analysis is not evidence of indefinite weekly coverage. [2]

For a fleet rollout, report initial validation and continuing scans separately. Where complete history shows validation alone, do not count that as recurring weekly coverage. Where a qualifying analysis is confirmed, verify later run records. Where analysis failed or history is missing, name the failure or evidence gap instead of converting silence into a security conclusion.

The evidence here is one GitHub vendor documentation chain, not an independent effectiveness study. The October 1 announcement says the change applies to Enterprise Cloud and will be supported in Enterprise Server 3.24; it does not establish that the server version has shipped or that any specific account has the behavior. The documentation pages were checked on October 12, but their publication and update dates are not established. [1][2][3]