GitHub Actions Retention Changes on October 1, 2026: What to Audit Now

Starting October 1, 2026, the retention setting in GitHub Actions will control more than artifacts and logs. Checks, workflow runs, and commit statuses will also be removed after the configured retention period.

That makes the setting an operational and compliance decision, not just a storage-cost control.

What Is Changing

GitHub currently keeps checks, workflow runs, and commit statuses for more than 400 days even when a shorter Actions retention period is configured. From October 1, those records follow the same policy as artifacts and logs.

The default is 90 days. Organization and enterprise caps still limit how high a repository can set its retention. Public repositories cannot retain these records beyond 90 days.

The policy also covers checks and statuses created by third-party integrations, not only records created by GitHub Actions.

Why This Can Surprise DevOps Teams

A green check on an old commit may be part of release evidence. A workflow run can explain which commit, environment, approver, and artifact created a production release. If your audit process assumes that evidence remains visible indefinitely, the new cleanup behavior creates a gap.

Changing the setting later will not restore records that GitHub has already deleted. Treat September as a migration window.

Audit the Current Retention Setting

Review the setting at enterprise, organization, and repository levels. In an organization, open Settings → Actions → General and locate Check, workflow run, status, artifact and log retention.

Build an inventory with these columns:

Do not blindly maximize every repository. Longer artifact and log retention can increase billable storage. Checks, workflow-run metadata, and statuses are not billed as artifact storage, but the logs and artifacts attached to those runs are.

Separate CI Convenience from Audit Evidence

GitHub Actions is an execution system, not necessarily your permanent evidence store. If evidence must outlive the allowed retention period, export the minimum required record to an approved archive.

A release evidence bundle might contain:

• commit SHA and repository
• workflow name and run ID
• actor and approval record
• deployment environment
• artifact checksum rather than a second artifact copy
• infrastructure plan or security scan summary
• timestamps and final conclusion

Protect the archive with retention locks, access controls, encryption, and an owner. Copying every log forever creates cost and privacy problems without improving audit quality.

Create a Safe Migration Plan

1. Identify repositories that produce production releases.
2. Map regulatory and customer requirements to an explicit number of days.
3. Compare the requirement with enterprise and public-repository caps.
4. Export evidence that must remain longer than GitHub allows.
5. Test retrieval from the archive before relying on it.
6. Record the owner and review date for each exception.
7. Recheck settings after October 1 and confirm old records expire as expected.

Common Mistakes

Do not assume raising retention restores deleted data. Do not use artifact retention alone as a compliance program. Do not archive secrets printed in logs. Finally, do not forget third-party commit statuses: the new policy applies to them too.

Bottom Line

The October 1 change makes your existing Actions retention value more powerful. Review it before cleanup begins, retain ordinary CI data only as long as it remains useful, and move long-lived release evidence into a system designed for records management.

For a broader runner strategy, compare GitHub-hosted, larger, and self-hosted runners.

Sources

• GitHub Changelog: Actions retention will cover checks, workflow runs, and statuses
• GitHub Docs: Configure retention for an organization