Can Increasing GitHub Actions Retention Restore Missing Checks?
An auditor opens last year’s release PR and finds its passing checks gone, including results from your external CI. What happened to them, and what can you still keep?
- A retention increase does not recover deleted checks or workflow history.
- Checks and commit statuses submitted by external CI integrations are covered too.
- Preserve needed logs while they remain available, then configure retention for new records.
Retention is not a recovery control
If an old release has missing PR checks, increasing the retention value will not bring back records already deleted. GitHub states this explicitly in its October 1 rollout notice.
There is a second limit to understand. The organization settings documentation says a customized period applies to new objects, not retroactively to existing ones. Extending future retention and recovering a past result are separate goals.
A missing item still needs investigation in its own repository. Absence from a view does not, by itself, prove retention deleted it. But when retention has removed the record, changing the setting is not a restoration path.
Running CI elsewhere does not preserve its GitHub records forever
The expanded policy covers checks, workflow runs and commit statuses alongside artifacts and logs. Checks and statuses created by third-party applications are included. An external CI service can retain its own records while the result it submitted to GitHub expires.
GitHub's workflow-log guide describes the relationship: each Actions run creates a check suite, with a check run for each job. An exported log is therefore not a complete backup of every related check field or PR conversation.
The consequence for automation is concrete. In a 2025 community report, missing commit statuses led a CI system to retrigger tests for a PR merged two years earlier. That report predates the October change; it illustrates the dependency on historical results remaining queryable.
Choose a period your repository and parent policies allow
The default is 90 days. The Enterprise Cloud repository settings guide allows 1–90 days for public repositories and 1–400 days for private and internal repositories. Organization and enterprise caps can impose a lower maximum.
| Repository type | Range | Constraint |
|---|---|---|
| Public | 1–90 days | Subject to parent policy limits. |
| Private or internal | 1–400 days | 400 days is a ceiling, not an automatic setting. |
Open the repository's Settings → Actions → General, enter the required number of days in the retention field covering checks, runs, statuses, artifacts and logs, and save it. Cache retention is a separate control.
For example, retaining new private-repository records for 180 days requires the parent policies to permit 180 days too. That example does not provide a way around the public-repository ceiling.
Save available logs before they expire
With read access, select the workflow and run under Actions, open the relevant job, and choose Download log archive from the log menu. The download instructions include an important detail for partial reruns: the archive contains only the jobs rerun in that attempt. Earlier attempts must be downloaded to collect the other jobs' logs.
Decide which evidence a release review actually needs: job output, check results or records held by the external CI system. Preserve what is still available, then set the period for new GitHub records. A longer retention value helps future history survive; it does not reconstruct missing history.