GitHub Actions Retention Now Covers Checks and Workflow Runs

As of October 1, 2026, GitHub applies the Actions retention setting to checks, workflow runs, and statuses, not only artifacts and logs.

The runner change that removed Node 20 is separate and is covered in GitHub Actions drops Node 20.

The change matters for teams that rely on older workflow history for troubleshooting, operational reviews, audits, or release investigations. GitHub says the default retention period is 90 days, and data is cleaned up after the configured period. Information already removed will not be restored by changing the setting later.

What the retention setting covers

The Actions retention setting now covers:

• Checks
• Workflow runs
• Statuses
• Artifacts
• Logs

The setting’s interface label is “Check, workflow run, status, artifact and log retention.” GitHub says checks, workflow runs, and statuses were previously retained for more than 400 days regardless of the configured retention value. They are now cleaned up when they exceed the applicable retention period.

The October 1 changelog says these records are cleaned up once they pass the configured retention period. Changing the setting later does not restore data that was already removed. The changelog does not describe the cleanup batch schedule.

Retention limits depend on repository and policy scope

The currently documented Actions artifact-and-log setting defaults to 90 days. For that setting, repository documentation lists a range of 1 to 90 days for public repositories and 1 to 400 days for private repositories.

GitHub’s announcement specifically states that checks, workflow runs, and statuses in public repositories have a maximum retention period of 90 days. GitHub’s October 1 changelog states that public repositories can retain these records for at most 90 days. Treat the 1-to-400-day range as the documented limit for private-repository artifacts and logs. The changelog does not restate that same private-repository range for every newly covered data type.

Higher-level policy settings also matter. Repository retention cannot exceed a limit imposed by its organization or enterprise, and an organization’s setting is likewise subject to limits from a managing organization or enterprise. Enterprise owners can enforce GitHub Actions policies through the enterprise administration settings.

Organization owners can configure the current artifact-and-log retention setting through the organization’s Settings, Actions, and General pages. The organization retention documentation describes that administrative path and the relationship between organization-level and higher-level limits.

Why the change matters for engineering teams

Workflow history is often useful after the run that created it has finished. Engineers may need an old check result to investigate a regression, compare release behavior, or understand why a deployment was blocked. If that history previously remained available for more than a year but now follows a shorter configured period, existing retention assumptions may no longer be valid.

The storage implications are not identical for all five data types. GitHub says artifacts and logs count toward billable GitHub Actions storage. Checks, workflow-run metadata, and status metadata are not billed for storage, although their associated artifacts and logs are. Increasing the retention period can therefore affect storage costs when it causes more artifacts and logs to remain available.

The change is not presented as a security vulnerability or security fix. Its main operational effect is the possible loss of historical records after automatic cleanup. Teams with audit, incident-response, or release-tracking requirements should decide which information must be preserved outside the default retention window.

What administrators should do

1. Review the retention setting now. October 1, 2026 has passed, and the broader cleanup is in effect. Check repository, organization, and enterprise policies to determine the effective limits for the projects that depend on historical Actions data.
2. Compare the configured period with operational requirements. Consider how long teams need checks, workflow runs, statuses, artifacts, and logs to remain available for troubleshooting or review.
3. Account for higher-level limits. A repository or organization cannot select a period beyond the limit imposed by its managing organization or enterprise. Public repositories cannot retain the affected checks, workflow runs, and statuses for more than 90 days according to the announcement.
4. Preserve important information before expiration. GitHub recommends exporting or archiving information that must remain available longer. The supplied documentation does not define a unified export format, archival API, or end-to-end archival workflow for all affected data types, so teams should not assume that one exists.
5. Plan for storage effects. Longer artifact and log retention can increase billable Actions storage, even though checks, workflow-run metadata, and status metadata themselves are not billed for storage.

For organization-level automation, GitHub documents REST endpoints to get and set the artifact-and-log retention value. The REST API documentation says the get response includes the configured number of days and the maximum allowed number of days. Organization administration authorization is required: classic OAuth or personal access tokens need admin:org, while fine-grained tokens need the relevant Administration organization permission.

The documented API does not establish a dedicated enterprise retention endpoint or a unified API for archiving checks, workflow runs, and statuses. It also does not provide a repository retention endpoint in the supplied material.

Important documentation caveat

There is an unresolved difference in GitHub’s documentation. The October 1 changelog says checks, workflow runs, and statuses are now governed by the shared Actions retention setting. Separately, the checks REST documentation still describes checks data as being retained for 400 days, archived, and permanently deleted 10 days later.

The supplied sources do not explain how that checks lifecycle is reconciled with the shared setting, or the exact schedule used to clean up records that already existed on October 1. Administrators should avoid assuming a specific cleanup batch process.

The practical takeaway is straightforward: review the effective retention policy now, preserve information that must outlive it, and do not rely on a later setting change to recover data that has already been evicted.

Sources

• GitHub Changelog: Actions retention now covers checks, runs, and statuses
• GitHub Changelog: Actions retention will cover checks, workflow runs, and statuses
• GitHub Docs: Managing GitHub Actions settings for a repository
• GitHub Docs: Configuring the retention period for GitHub Actions artifacts and logs in your organization
• GitHub REST API: Actions permissions
• GitHub REST API: Interact with checks