GitHub's scheduled code scans may never start at all

A repository with code scanning enabled, one green validation scan in its history, and nothing since looks exactly like a repository that is being scanned weekly and coming up clean. That is the problem with both of GitHub's 1 October Code Quality changes. Neither is wrong as engineering. Both make a signal quieter, and a quiet signal is harder to notice than a broken one.

The change: scheduled scans are now activity-gated

GitHub's changelog entry is one sentence of substance: “Weekly scheduled scanning only begins once a push or pull request triggers an analysis.” It applies to code scanning default setup and to GitHub Code Quality. The initial validation scan still runs when you enable default setup. It is live on GitHub Enterprise Cloud and is slated for GitHub Enterprise Server 3.24. And: “No configuration change is needed on your part.”

The motivation is obvious and defensible. Organisations enable default setup across hundreds of repositories at once, most of which are archived in spirit if not in flag, and each of those was burning Actions minutes on a weekly CodeQL run over code nobody had touched in a year. Gating the schedule on activity is the right economic call.

The problem is the state it produces. Enable default setup on a dormant repository today and you get one validation scan and then nothing, indefinitely. GitHub's announcement promises no banner, warning or status entry to tell you the schedule never started. The security tab shows a successful analysis. The absence of subsequent ones is indistinguishable from the absence of findings.

There are now two inactivity rules, and only one is documented

This is the part worth your attention, and it is the kind of gap that only shows up when you read the changelog against the reference documentation it should have updated.

GitHub's page on configuring default setup for code scanning already carried an inactivity rule before 1 October: “If no pushes and pull requests have occurred in a repository with default setup enabled for 6 months, the weekly schedule will be disabled to save your GitHub Actions minutes.” The same page notes that organisation owners can enable monthly scans of inactive repositories, pointing at the global security settings page.

That is a stop rule, with a number attached: six months of silence disables the schedule. The 1 October change is a start rule, with no number attached: the schedule does not begin until something triggers an analysis. They are different mechanisms, and as of writing the documentation page describes the first and not the second.

Vendor reference pages lagging vendor changelogs is a pattern rather than an accident at this point. We have watched the same thing with Actions runner metadata, with npm's audit endpoints, and with the Actions artifacts REST reference. The practical rule: when a changelog and a docs page disagree about current behaviour, the changelog is newer and the docs page is what your team will read.

The second change: coverage uploads now skip quietly

Shipped the same day, the other entry fixes a real annoyance in the upload-code-coverage action. The coverage API required a pull request number for any push to a non-default branch. That number only exists once a PR is open, so pushing a new branch before opening the PR failed the coverage-upload step. Legitimately broken behaviour, legitimately fixed.

The new behaviour: when the action runs on a branch with no associated pull request, it “skips the upload instead of failing, and explains why in an Actions notice and step summary”. Default-branch pushes and supported pull request events are unaffected. No workflow changes are required. It is available on GitHub Enterprise Cloud, GitHub Team, and GitHub Enterprise Cloud with data residency — not on GitHub Enterprise Server.

There is a configuration note buried in it that will catch teams out. If you want coverage uploaded automatically when a pull request is created, you need a pull_request trigger in your workflow. A push-only workflow will now run green on every feature branch and upload nothing. Before 1 October you would have found that out immediately, because it failed. Now you find out when someone asks why the coverage trend has a gap.

And an Actions notice is a weak place to put important information. Notices do not fail builds, do not appear in a required-check status, and are not something anyone reads on a passing run. The step summary is better but still only read deliberately.

What to change this week

Audit for repositories with exactly one analysis

The signature of a repository caught by the start rule is one analysis, dated the day default setup was enabled, and nothing after it. That is queryable across an organisation and it is the single highest-value check to run right now. Anything on that list is either genuinely dormant and fine, or dormant-looking and shipping to production from a tag, which is the dangerous case.

Decide about monthly scans explicitly

The org-level option to enable monthly scans of inactive repositories exists precisely for the case where “inactive” and “unimportant” are not the same thing. A vendored library, a deployed-but-frozen service, an internal tool nobody commits to and everyone uses — those want a monthly scan. Make it a decision rather than a default, the same discipline GitHub's Copilot default-enablement deadline forced on Copilot features.

Add the pull_request trigger now

If your coverage workflow is push-only, add the trigger before the gap in your coverage data gets long enough to be embarrassing. While you are in the workflow file, it is worth checking what else is pinned there: this is the same stretch of calendar carrying the ubuntu-latest move to Ubuntu 26.04 and the default block on pull_request_target, and one editing pass can cover all three.

Stop treating a green run as a scanned run

The general lesson outlives both of these specific changes. If a control matters, assert on its freshness, not on the absence of an error. “Last analysis is older than N days” is a check you can write; “no failures” is not a check at all. A diff of two workflow files in the text diff checker is often the fastest way to see which repositories drifted, and the cloud and DevOps category covers the tools that will alert on staleness if GitHub will not.

FAQ

How many days of inactivity stops a scheduled scan from starting?

GitHub publishes no day threshold for the 1 October behaviour. It is activity-gated rather than time-gated: the weekly schedule begins once a push or pull request triggers an analysis. The separate six-month rule, which disables an already-running weekly schedule, does carry a number and is documented on the default setup page.

Does the initial scan still run when I enable default setup?

Yes. Enabling default setup still triggers a validation scan of the generated configuration immediately. It is the recurring weekly schedule, not the first scan, that now waits for a push or pull request.

Can I opt out of the activity gating?

The changelog documents no opt-out and states that no configuration change is needed. The nearest lever is the organisation-level setting for monthly scans of inactive repositories, in your organisation's global security settings.

Which plans and products are affected?

The scheduled-scanning change applies to code scanning default setup and GitHub Code Quality on GitHub Enterprise Cloud, with GitHub Enterprise Server 3.24 support stated as coming. The coverage-upload change is available on GitHub Enterprise Cloud, GitHub Team and GitHub Enterprise Cloud with data residency, and is not available on GitHub Enterprise Server.

Why would a coverage upload now be skipped?

Because the action ran on a branch with no associated pull request. The coverage API needs a pull request number for pushes to non-default branches, and rather than failing the step the action now skips the upload and explains itself in an Actions notice and the step summary.

Do I need to change my workflow for coverage?

Not to stop the failures — that is automatic. But if you want coverage uploaded automatically when a pull request is created, GitHub says to add a pull_request trigger to your workflow. A push-only workflow will now pass and upload nothing on feature branches.

A control you cannot prove ran recently is not a control. It is a checkbox.