GitHub splits Code Quality off the Actions billing meter

GitHub gave Code Quality CodeQL workflows their own Actions path, per an August 20 changelog. The direct operational consequence lives in two places: the Actions bill and the workflow-run list. Code Quality runs no longer count against the same minute quota as the rest of a repo's CI, and no longer sit in the same run history as its deploys.

What actually got split

The changelog is compact. A dedicated workflow path for Code Quality CodeQL Actions workflows is now generally available. Workflow-run history separates Code Quality runs from regular Actions runs. Actions usage reports do the same. That is the whole mechanism, and it is the mechanism that matters.

Under the previous shape, a repo running CodeQL as its Code Quality engine paid twice for one product decision. It paid in minutes, because those workflows executed on the same runner pool everything else used, and were counted against the same quota. It paid in signal, because a matrix of CodeQL jobs on push, PR and schedule crowded the workflow list next to the deploys and integration tests you actually needed to find during an incident. The split does not add a feature. It removes the accounting collision.

Where this bites your bill

For a mid-sized repo the number to watch is the ratio between what CodeQL burns and what the rest of your CI burns. On any codebase where SAST is a nontrivial share of monthly Actions minutes, and that is common once you have several languages in the scan matrix and a full sweep running on every push, the split changes what a "cost overrun" alert on Actions actually means. If your quota-based alerts fired on Code Quality runs before, they will stop. If they fired on everything else, they will fire cleaner.

The direction follows a pattern. GitHub is separating the meter for its own security engine from the general-purpose meter it sells to everyone. That has an upside and a catch. The upside is one fewer confounder in a bill review. The catch is that the two meters can drift, and you have to wire whichever new usage report the platform exposes into the same finance dashboard the general Actions meter already sits on. Otherwise the Code Quality spend moves from visible and blamed to invisible and unblamed, and invisible spend is the harder kind to fix.

Housekeeping in the workflow history

The other half of the change lives in the run list. Under the old shape, an on-call engineer reconstructing why a deploy failed had to scroll past whichever CodeQL matrix legs finished in the same window. Not fatal, but toil. With Code Quality runs out of the main list, the general-purpose workflow history reads as what it is again: the runs that build, test and deploy your code.

The audit consequence is the mirror image. Any log-shipping pipeline that treats the main workflow feed as canonical needs to point at both paths now. Retention and export tooling hardcoded to the old layout will silently drop Code Quality events from the archive until you update it. That is the sort of gap that shows up months later, when a compliance auditor asks for a full year of SAST runs and you can produce eleven months of them.

The knob you still don't have

Read the changelog for what it does not say. Code Quality still runs on Actions infrastructure. The same broken toolchain that stalls your regular runners stalls the SAST runners. The same regional degradation drags both. And, so far as this changelog says, there is no separate SLA for the Code Quality path. The meter is carved off from the general one; the substrate is not.

Continuity caveat. The split changes billing and observability. It does not add isolation. Treat it that way in your finance dashboards, treat it that way in your incident playbooks, and you get the value of the change without expecting a reliability guarantee the changelog never made.