Your CI History Now Expires With Your Build Artifacts

What Changes on October 1

GitHub announced on August 27, 2026 that one setting is about to govern considerably more than it used to:

Checks, workflow runs, and statuses will follow your Actions retention setting.

Until now they did not:

Until now, checks, workflow runs, and statuses were retained for 400+ days regardless of your retention configuration.

The setting has been renamed to match its new reach, and now reads "Check, workflow run, status, artifact and log retention". The default is 90 days. For public repositories the maximum is 90 days, matching the existing cap for artifacts and logs, and organization and enterprise administrators can set lower caps that apply downwards.

Why This Catches People

Nothing about the change is unreasonable, and that is exactly what makes it easy to miss.

The Actions retention setting has always been an artifact storage decision. Artifacts are large, storage is billed, and lowering the number is the standard first move when someone looks at the bill. Plenty of teams set 7 days, or 14, and moved on years ago. That was a sensible answer to the question being asked.

From October 1 the same number decides how long you can see that a build ran at all. A team on 7 days keeps a week of build history, and everything older disappears. Nobody will change a setting, nobody will get a warning at the moment it happens, and the history will simply not be there the next time someone goes looking.

The gap between deciding and noticing is the problem. Retention was chosen to control storage cost and is now controlling an audit trail, and the two want very different numbers.

Who Should Care Most

Anyone with a compliance obligation. If an auditor has ever asked you to show that a specific commit went through review and passed its checks before it reached production, that evidence is a workflow run. A 14 day window will not answer a question about last quarter.

Anyone debugging flaky infrastructure. The value of run history is comparative. "This job has failed intermittently since roughly May" is a sentence you can only write with months of runs behind you, and it is usually how an intermittent fault gets caught at all.

Anyone who lowered the cap centrally. An organization or enterprise cap applies to every repository under it. One decision made once, for artifact storage, is about to apply to the run history of every team in the organization.

Open source maintainers. Public repositories are capped at 90 days and cannot go higher. If long lived run history matters for a public project, it has to be exported.

What To Do Before October 1

Read your current number. Repository, organization and enterprise each have a setting, and the effective value is the lowest cap that applies. Check the level you actually control.

Decide it twice. Ask what retention you want for artifacts, then ask separately what retention you want for run history, and set the value to the larger of the two. They were never the same question; until now the tooling let you pretend they were.

Export what has to outlive the window. GitHub's own advice is direct:

Export or archive anything you need to keep beyond your configured retention period.

For most teams that means the compliance evidence rather than everything. The Actions API can list workflow runs and their conclusions, and a scheduled job that writes those to object storage is a small amount of work compared with reconstructing them later.

Budget for it if you raise the number. Artifacts and logs are what cost money, and they share the setting. Raising retention to keep run history also keeps more artifact bytes. If the artifact bill was the reason the number was low, the fix is to stop uploading artifacts you do not need rather than to accept a short history.

The Wider Point

Pipelines accumulate settings that were correct for one reason and then quietly acquire a second job. This one comes with a date and a changelog entry, which is the good version of the problem. The bad version is the setting nobody announced.

It is worth an hour, once, to write down what each pipeline setting is actually for. Retention, concurrency limits, timeout values and runner labels all started as answers to a specific question, and most teams cannot say what that question was.

We build and maintain CI/CD pipelines and the security and compliance evidence they produce. This is the second GitHub change in a fortnight that quietly widens what one control reaches, after credential revocation by token type. If you want someone to look at what your pipeline could prove about a deploy from six months ago, get in touch.

Sources: GitHub Changelog, August 27 2026, GitHub docs on usage limits, billing and administration for GitHub Actions