Since October 1, 2026, the GitHub Actions retention policy no longer stops at artifacts and logs. GitHub's changelog says checks, workflow runs and statuses "are now governed by the same GitHub Actions retention setting" that already covers artifacts and logs. If your repos sit on the default, old check results and run records are now eligible for cleanup. Raising the setting later won't bring back anything already removed, and per the docs it doesn't reach existing data at all. So the order of work matters: export what exists now, then raise retention for what comes next.
What the setting now deletes
Three kinds of data fall under it. The organization retention docs put it this way: "These retention policies apply to checks data, including check suites and check runs, and to commit statuses, including those created by third-party integrations." Workflow runs are covered too, per the changelog.
The setting was renamed to match. It's now "Check, workflow run, status, artifact and log retention", and you'll look for that label in the settings pages below.
The changelog is the authority on timing. The docs pages still read "Starting October 1, 2026, these policies will apply...", so don't be thrown if they sound like the change is pending.
One line from the changelog is worth keeping in front of whoever owns this: "Changing the setting won't restore data that was previously removed."
How long you can keep it
Public repositories top out at 90 days. Private and internal repositories can go to 400. The docs say you can set the period "anywhere between 1 day or 400 days" for private repos and "between 1 day or 90 days" for public ones. GitHub's August announcement gave the default as 90 days.
A repository's value is also bounded from above. Repository settings stay subject to organization and enterprise limits, so the lowest cap in the chain wins.
| Scope | Where to set it | Maximum |
|---|---|---|
| Repository | Settings > Actions > General > "Check, workflow run, status, artifact and log retention" | 90 days public, 400 days private |
| Organization | Settings, then Actions in the left sidebar, then General. Under the retention heading, enter a new value and click Save | 90 days public, 400 days private |
| Enterprise | Open your enterprise, click Policies, then Actions under Policies | Public 1-90 days, private and internal 1-400 days |
The click paths come from the docs for repository settings and enterprise policies, plus the organization page linked earlier.
Find out what your repos are set to today
Start at the top and work down. Check the enterprise policy, then each organization, then the repositories that matter. If an organization caps private repos at 90 days, a repo-level value of 400 means nothing, because the narrower limit binds.
Prioritise by what reads the data. A repo that nobody looks at after a merge can sit on the default. A repo whose history feeds an audit sample or a metrics dashboard can't. Make that list first, with a named owner per repo, and keep it short enough that someone actually finishes it.
Who reads old runs
This is judgment, not a GitHub claim. These are the places where a shorter window is likely to bite, roughly in order of how often they're forgotten.
- Audit samples. If your change-management evidence relies on screenshots or exports of passing checks and required reviews on merged commits, anything older than your retention window may no longer be there to pull. Ask your auditor what they sample and how far back, then compare it to the setting.
- DORA tooling. Deployment frequency, change failure rate and lead time are often computed from run history. If your dashboard looks back further than your retention, the older points will go flat or vanish. Our piece on how DORA metrics are calculated covers what the numbers are built from.
- Dashboards and scripts with a long lookback. Anything that queries runs or statuses for a quarter or a year will return less than it used to.
- Incident reviews. A post-mortem that wants to compare a bad deploy to last quarter's runs needs those runs to exist.
How to export before it is gone
Start copying out existing history now, and raise the setting for what comes next. All of it uses the REST API. GitHub's docs describe REST endpoints for reading this data, not a bulk-export feature, so treat any script you write as your own glue code.
1. Raise retention for new data
Set the longest value the cap allows on the repos on your list: 400 days for private and internal repos, 90 for public. The docs say a customized period "only applies to new checks, workflow runs, commit statuses, artifacts, and log files, and does not retroactively apply to existing objects." It won't protect or recover what exists today, so start steps 2 to 5 without waiting on it.
2. List the workflow runs
Call GET /repos/{owner}/{repo}/actions/runs and fetch each run with GET /repos/{owner}/{repo}/actions/runs/{run_id}. The workflow runs reference gives the page size as 30 by default and 100 at most. It also says the list endpoint returns up to 1,000 results for each search when you use any of these parameters: actor, branch, check_suite_id, created, event, head_sha or status. Splitting the job into date windows is the usual way around that. Logs for a run come from GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs.
3. Pull the check runs per commit
For the commits you care about, call GET /repos/{owner}/{repo}/commits/{ref}/check-runs. You can also go by suite with GET /repos/{owner}/{repo}/check-suites/{check_suite_id}/check-runs, or fetch one with GET /repos/{owner}/{repo}/check-runs/{check_run_id}. The check runs reference notes that classic tokens need the repo scope on private repositories.
4. Pull the commit statuses
Use GET /repos/{owner}/{repo}/commits/{ref}/statuses for the full list, or GET /repos/{owner}/{repo}/commits/{ref}/status for the combined state. The commit statuses reference says pull access is enough.
5. Store it somewhere with its own rules
Put the export in storage with its own retention period and access control, not in the repo it came from. Strip secrets from logs before you archive them, because a log you keep for a year is a secret you leak for a year. Then test retrieval: pick one old merge and confirm you can rebuild its checks from the archive.
What this means for your audit evidence and metrics
For every repo that feeds an audit sample or a DORA dashboard, decide two things this week: who owns it, and whether it gets longer retention, a scheduled export, or both. As a judgment call, do both for anything private, since 400 days is a ceiling, not an archive.
Raising retention applies to new data, per GitHub's docs, so export what already exists now rather than relying on the new value to protect it. Then raise retention for what comes next. Ask each owner how far back their evidence needs to reach and check whether that history still exists.
If this is one of several platform changes landing on your team, the Platform and language release notes: what breaks and what to fix hub tracks them in one place. The macos-14 runner retirement is another Actions change this month.
FAQ
Can I recover runs already deleted?
No. GitHub's changelog says: "Changing the setting won't restore data that was previously removed." The docs add that a new retention value applies only to new objects, so export what exists before anything else.
Does this affect private repos?
Yes. Private repositories can keep checks, runs and statuses for 1 to 400 days, so they have more headroom than public repos, which max out at 90. The default is 90 days unless someone has set it higher.
What is the longest I can keep checks?
400 days, on private and internal repositories. Public repositories can go to 90 days. An organization or enterprise limit can cap a repository below those figures.
Does Enterprise Cloud work differently?
Not in the limits. The enterprise Actions policy takes public values of 1-90 days and private and internal values of 1-400 days, and repository settings stay subject to those limits. The click path is Policies, then Actions.