GitHub Actions Retention Expands on October 1

GitHub is changing how long several types of Actions-related history remain available. Beginning October 1, 2026, checks, workflow runs, and statuses will use the existing GitHub Actions retention setting alongside artifacts and logs.

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 will be cleaned up after the configured period. Information already removed will not be restored by changing the setting later.

What changes on October 1

Today, the Actions retention setting is documented primarily as an artifact-and-log setting. GitHub’s announcement says that, from October 1, the same setting will govern:

• Checks
• Workflow runs
• Statuses
• Artifacts
• Logs

The setting’s interface label will change to “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. After the change, they are expected to be cleaned up when they exceed the applicable retention period.

The GitHub announcement identifies October 1, 2026, as the effective date. It does not specify whether existing checks, workflow runs, and statuses will be processed in a single migration, in batches, or through another cleanup mechanism.

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. The supplied documentation does not explicitly confirm that every affected data type will use the same 1-to-400-day range for private repositories after October 1. Teams should therefore treat the private-repository range as the current documented limit for artifacts and logs, not as a fully confirmed future limit 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 will soon follow 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 retention settings before October 1, 2026. 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 timing difference in GitHub’s documentation. The future-facing changelog says checks will join the shared Actions retention setting on October 1, 2026. Separately, the current checks REST documentation describes checks data as being retained for 400 days, archived, and permanently deleted 10 days later.

These descriptions may apply to different points in time, but the supplied sources do not explain how the current checks lifecycle will be reconciled with the future shared setting. GitHub also has not documented the precise treatment of checks, workflow runs, and statuses that already exist before October 1. Administrators should avoid assuming a specific migration schedule or 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 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