GitHub Actions retention expands: keep release evidence beyond a green check
On deployment day, a green check and a workflow URL can feel like a complete release record. Months later, an investigation may find that the link has expired. Remembering that a build passed and being able to explain what passed are two different operational assets.
GitHub announced on October 1, 2026 that Actions retention now also governs checks, workflow runs and statuses. Teams that treated retention as a logs-and-artifacts concern should revisit where release evidence lives. The procedure below is an engineering proposal based on that change, not an additional GitHub requirement.
Start with the scope of retention
Records beyond the configured period are automatically cleaned up, including checks and statuses from third-party applications. Repository settings remain subject to organisation and enterprise caps; public repositories have a 90-day maximum. Raising a setting does not restore records already removed.
The first decision is not simply whether to keep everything longer. Find releases whose only proof is a workflow URL. Signature checks, test results, approvals and artifact hashes may live in different systems. Ask whether an investigator can still connect those facts when any one link becomes unavailable.
Build one release evidence bundle
A useful starting bundle contains the commit SHA, release name, run ID and URL, result time, test summary and artifact hash. If a person approved the release, record who approved what. Avoid copying raw logs containing tokens, passwords or personal information; decide the purpose of retention and the people allowed to read it.
A line saying passed cannot explain the scope of a check. If only part of a test suite ran, describe that boundary. Preserve the relevant runtime and dependency-lock information and point to files at the release commit, rather than their current branch versions. Otherwise later changes can make an old release look as if it ran with today's configuration.
Test the export before automating it
Choose one repository and one release for a pilot. Read the repository setting and organisation cap, save the necessary summary separately, then ask another person to explain the release without opening the original workflow link. This reading exercise exposes missing context before an automated collector reproduces the same gaps across every release.
Exporting creates another security boundary. Define an owner, retention period, editing rights and secret-removal criteria before moving logs elsewhere. Permanent storage of every debugging line is not the goal. Keep the durable explanation of a deployment separate from short-lived troubleshooting material, so operational convenience does not become unnecessary disclosure.
Do not interpret missing history as failure
A missing check raises a diagnostic question: did retention, permissions or query conditions hide the record? An empty API response alone does not establish that a test never ran. Compare the original run ID, observed settings and independent release evidence. This article treats that confusion as a practical question, without claiming measured community sentiment.
This week, add evidence locations and expiry dates to your release template and read back one completed bundle. A longer CI retention period alone cannot guarantee every audit requirement. The concrete objective is to recover a defensible explanation of a release when it is needed, with clear scope and controlled access.