GitHub cuts Actions check and run retention from 400+ days to 90 on 1 October
From 1 October 2026, GitHub applies the same retention setting to checks, workflow runs and statuses that already governs artifacts and logs — 90 days by default instead of more than 400. Teams that rely on that history must review their setting and export what they want to keep.
27 August 2026. GitHub announces the change in its changelog. 1 October 2026. The new retention takes effect. 90 days. That is the default window replacing a history of more than 400 days. In one announcement, part of the operational memory of CI/CD pipelines shifts from implicit to configurable — and whatever is not configured will be purged.
What changes exactly
Until now, checks, workflow runs and statuses in GitHub Actions were kept for more than 400 days, regardless of the repository’s retention setting. That setting governed only artifacts and logs.
From 1 October 2026, all five elements fall under the same rule: checks, workflow runs, statuses, artifacts and logs. They will be cleaned up automatically once the configured period is exceeded, with a default of 90 days.
The UI label changes accordingly — it becomes “Check, workflow run, status, artifact and log retention” — but it is the behaviour that matters. A history teams took for granted will now depend on a setting many have never opened.
What does not change, and why it matters
Three guardrails frame the purge. First, the change is not retroactive: adjusting your setting will not restore data that was already evicted. Second, a repository can only raise its retention up to the cap set at the organisation or enterprise level. Third, for public repositories, the maximum is 90 days, matching the existing limit for artifacts and logs.
Those three points draw the real stake. A public repository will never be able to keep its checks beyond 90 days, no matter what you do. A private repository cannot exceed its organisation’s cap either. The room to manoeuvre lies between the default and the cap — not beyond it.
Why GitHub is changing now
The official motivation fits one sentence from the changelog: reduce the amount of stale data stored across GitHub Actions to keep checks, workflow runs and statuses “fast and reliable for everyone”. In plain terms, it is an infrastructure trade-off — millions of repositories keep hundreds of days of history almost no one re-reads, and that storage has a real cost.
The choice of date — 1 October — is not incidental. It leaves organisations a little over a month to adjust their settings, consistent with GitHub’s practice of announcing behaviour changes before applying them. The precedent of artifacts and logs, already subject to this retention, served as the test bed.
What changes in kind is extending the rule to data teams treated as permanent. Where artifacts are build files everyone knows are ephemeral, checks and runs are felt as the living history of a project. The transition from one to the other is the real subject.
The audit and investigation angle
For a platform team, a workflow run is not just a status screen. It is a record: who triggered what, with which commit, producing which result and artifact. Teams use it to reconstruct an incident, prove compliance, or answer an audit.
Dropping from 400 days to 90 days compresses that memory by more than a factor of four. An investigation reaching back six months will no longer find the history of checks and statuses — only artifacts and logs will remain, if they are themselves still within the window.
The distinction between metadata and content matters here. GitHub notes that check, run and status metadata are not billed, but the artifacts and logs associated with them are. The data most useful to an audit — the run history — is precisely the data that will evaporate for free.
The cost angle
Billing follows a simple logic: lowering retention removes artifacts and logs sooner, which reduces billed storage. Raising it keeps them longer and can increase the bill.
The trap is the asymmetry. Check and run metadata costs nothing to keep — yet it will now be purged on the same schedule as the paid artifacts. In other words, the free data disappears in order to save on the paid data. That is a trade-off every team should make consciously rather than inherit by default.
Retention is not a backup
One frequent confusion must be cleared up. Purging checks and runs does not delete code, commits or tags: the repository itself stays intact. What disappears is the execution record — the fact that a specific commit produced a specific result on a given date, with a given artifact.
That distinction has a direct consequence for archiving. If a team must prove, months later, that a build passed or a test succeeded, it has to export that record itself. Run logs, test reports, deployment metadata: anything not versioned in the repository now falls under an explicit export policy.
In practice, this means using the GitHub Actions API or the gh CLI to list and export runs before the deadline, or relaying into an observability system that keeps its own history. Anyone who discovers the need after 1 October will not be able to recover it.
What to do before 1 October
For most repositories, no action is required: the clean-up will follow the setting already configured. But “most” is not “all”.
First, review the retention setting for the repository, the organisation and the enterprise. Confirm it reflects how long you actually need checks, runs and statuses — not just artifacts.
Then, raise the period if necessary, within the caps. Bear in mind that longer retention also keeps artifacts and logs around longer, with a possible impact on billing.
Finally, export or archive anything you must keep beyond the window. Older items will be removed automatically once the change takes effect, and nothing will restore them.
Concretely, start with the organisation-level setting, since it caps everything beneath it. Then inventory what exists today — gh run list and the Actions API both expose the run history — and schedule an export of anything older than your target window. Set a calendar reminder for the last week of September; the change is not retroactive, so anything not exported by 1 October is gone for good.
Separate two questions that are easy to conflate. How long you keep builds is a storage question; how long you can prove what ran is an evidence question. The October change answers the first, and the second is now entirely yours to answer.
For regulated teams — finance, healthcare, anything under an audit regime — the ninety-day default is unlikely to be enough, and the public-repository cap of ninety days means open-source projects have no way to extend it at all. That is a hard constraint to plan around, not a setting to tweak after the fact.
Verdict
If your pipelines only build and deploy, change nothing: the 90-day purge will likely save you storage with no operational cost.
If you depend on check and run history for audit, compliance or incident investigation, act before 1 October 2026: raise retention to the allowed cap where necessary, and set up a regular export of what you must keep beyond it. A CI/CD record that was never judged valuable becomes, overnight, a record that no longer exists.