GitHub Is About to Expire Your Check History

GitHub has folded checks, workflow runs and commit statuses into the same retention setting that already governs artifacts and logs. Checks, workflow runs and statuses previously had their own retention behaviour, running to 400 days or more. They no longer do, and that detail is the substance of the change rather than a footnote to it: for most repositories this is a reduction, not a consolidation between two settings that already matched. The changelog went out on October 1, 2026, and it contains one sentence that matters more than the rest of the entry: changing the setting will not restore data that was previously removed. Whatever history you have already lost under the old behaviour is gone, and whatever you have not exported yet has a deadline.

The setting is now labelled “Check, workflow run, status, artifact and log retention”, it applies to checks and statuses produced by third-party applications as well as GitHub Actions, and public repositories have a hard ceiling of 90 days. The practical exposure is not CI runtime — nobody notices missing run logs. It is the quiet dependencies on long-lived check history: release provenance, audit evidence, flaky-test trends, and external dashboards that poll the Checks API as a system of record.

Key takeaways:

Checks, workflow runs and statuses now expire with the same retention policy as artifacts and logs.
Third-party applications that write checks are in scope, not just GitHub Actions.
Public repositories are capped at 90 days. There is no configuration that exceeds it.
Reduction is irreversible. The changelog states plainly that changing the setting back will not restore removed data.
Your organisation or enterprise may impose a lower cap than the repository setting, so raising the repo value may not be sufficient.
This does not change which status checks are required to merge. It changes how long you can prove a check ever ran.

Table of Contents

What actually changed

Aspect	Detail
What expires	Checks, workflow runs and statuses
Governed by	The same retention setting as artifacts and logs
Setting label	“Check, workflow run, status, artifact and log retention”
Producers in scope	GitHub Actions and third-party applications
Public repo ceiling	90 days maximum
Org/enterprise override	Repository setting remains subject to organisation and enterprise caps
Reversibility	None. “Changing the setting won’t restore data that was previously removed.”
Applies to	GitHub Actions on github.com

GitHub Changelog, 1 October 2026.

The 90-day ceiling is the real constraint

For a private repository under an enterprise plan, retention is a budget decision and you already had to make it. For a public repository, 90 days is not a setting you can choose — it is the maximum, and it is short enough to break quarterly and annual review processes on its own.

Public repositories include a great deal of software that is consumed as a dependency, forks of internal work, teaching material, and side projects. For any of those, the honest question is whether anyone is relying on check history older than a quarter for anything. Usually not. Occasionally, yes — and when yes, it is usually an audit requirement that someone discovered they could not satisfy.

Note also that the repository-level setting sits underneath organisation and enterprise policy. Raising it to the maximum does nothing if policy caps it lower, and the changelog does not say what happens in that case beyond stating the relationship. If you are inside an enterprise, check the policy value rather than assuming the repository setting wins.

What quietly depends on durable check history

Nothing in a typical CI pipeline breaks when run history disappears. Jobs still run, checks still gate merges, badges still resolve. The dependencies are further out and mostly invisible, which is exactly what makes them easy to miss.

Release provenance. “Which commit was on main when version 2.4.0 shipped, and did CI pass on it?” is a question most teams can answer from tags. But “was the dependency scan clean on that commit six months ago” needs the check record.
Audit and compliance evidence. If anyone has to demonstrate that a control operated on a date in the past, the check record was the artefact. This is the dependency that turns a retention setting into a compliance problem.
Flaky-test trend analysis. Any tooling that computes flakiness rates over weeks or months needs the history. Below the retention window it starts producing confidently wrong numbers, which is worse than producing nothing.
External dashboards and SIEM integration. Anything polling the Checks API as a system of record will start seeing gaps, and gaps in a compliance feed read as silence rather than absence.
Post-incident review. The investigation six weeks later that asks “was this test already failing?” is the most common real-world consumer of run history, and it is the one nobody budgets for.

What this does not change

Being precise here prevents a lot of unnecessary panic in issue threads:

Required status checks are unaffected. Which checks must pass in order to merge is a branch protection setting, stored separately. Losing history does not unblock a pull request.
Workflows are unaffected. The definitions run exactly as before. This is a storage policy, not an execution change.
Nothing about the current run breaks. A workflow in flight when retention passes will complete and its own retention then applies.
It is not a deprecation with a deadline. This is already in effect. The changelog carries no future migration date.

What to do this week

Find the setting and set it deliberately. Do not inherit whatever value the repository currently has. For a public repository, accept that 90 days is the ceiling and design around it.
Export anything already expiring that you need. If you have an audit or provenance requirement with a horizon longer than your retention window, export to somewhere you control now. The irreversibility sentence is the reason to do this before you need it.
Audit third-party check producers. Apps that write checks are now inside the same policy. Their output expires on your repository’s schedule, which you may not have considered when you installed them.
Check your organisation or enterprise policy value before assuming the repository setting is authoritative.
Tell your dashboard owners. If something external consumes the Checks API as a source of truth, that integration needs a stated retention assumption before the gaps start.
Decide what “no data” means in your flakiness tooling. A gap should be reported as a gap, not imputed as a pass.

Why this happened

The most plausible reading, given the changelog’s own framing, is consolidation: one retention control instead of several, applied uniformly across everything a run produces. That is a reasonable product decision and it reduces a genuinely confusing settings surface.

The cost is that a setting most teams set once, years ago, to control artifact storage now silently governs a different class of data. And unlike artifact storage, check history tends to be load-bearing for reasons that were never stated at the point the original setting was chosen. That gap between what a setting was chosen for and what it now governs is the whole of the risk.

It is worth auditing the other retention-style settings in your CI stack with the same question: what did I set this for, and what has quietly come under it since?