gitdash

GitHub Actions Retention Changes in October 2026: Checks, Runs, and Statuses

GitHub Actions will apply your retention setting to checks, workflow runs, and statuses from October 1, 2026. Here is what changes and how to archive important history.

A glowing workflow timeline moves through a retention gate toward an archive while older records fade away

GitHub Actions retention is getting a wider scope on October 1, 2026. The retention setting that already controls artifacts and logs will also control checks, workflow runs, and statuses. GitHub's announcement says the default remains 90 days, while public repositories can retain these records for at most 90 days.

Until now, checks, workflow runs, and statuses could remain available for more than 400 days even when a repository used a shorter artifact and log retention period. That makes the change easy to miss: your old run history may suddenly be shorter than the history you have grown used to. Read the official retention announcement before changing a policy that supports audits or incident review.

What changes on October 1

The same repository, organization, or enterprise setting will govern five kinds of Actions data: checks, workflow runs, statuses, artifacts, and logs. GitHub plans to rename the setting in the UI so the broader scope is visible. Records older than the configured retention period will be cleaned up automatically.

The change is not retroactive. Changing the setting does not restore data that has already been removed. It is also subject to higher-level caps, so a repository cannot choose a value above the organization or enterprise maximum.

Start by checking the setting

In a repository, open Settings, then Actions, then General. Find Artifact and log retention and note the current number of days. GitHub's repository settings documentation describes the UI path and the limits for public and private repositories.

gh api repos/OWNER/REPO/actions/permissions/artifact-and-log-retention

The API response gives you the repository's configured retention value. Replace OWNER and REPO, and authenticate gh with a token that can read the repository's Actions settings. For an organization-wide review, repeat this for repositories that produce records you need to keep.

Choose retention by use case

  • Fast-moving application builds: 14 or 30 days may be enough when the useful question is “what broke recently?”
  • Release workflows: keep records through the support window for the release, then export the evidence your team needs.
  • Security and compliance workflows: document the required history, then store durable evidence outside the default Actions retention window.
  • Public repositories: plan around the 90-day maximum. A longer repository value will not extend checks, workflow runs, or statuses beyond that cap.

Archive the useful part before it expires

Retention is not an archive strategy. If a release needs a permanent test report, upload that report to a system with the retention and access policy you actually require. GitHub's artifact documentation explains that individual artifacts can use retention-days, but that value cannot exceed the repository, organization, or enterprise limit. The artifact storage guide also shows the upload pattern.

- name: Upload release report
  uses: actions/upload-artifact@v4
  with:
    name: test-report-${{ github.sha }}
    path: reports/
    retention-days: 30

For longer-lived evidence, copy the report to your release system, object storage, or compliance archive during the workflow. Store the commit SHA, workflow run URL, test result, and release identifier together. That makes the exported record useful after the GitHub run itself is gone.

What this means for pull requests

Checks are part of the merge conversation. GitHub documents that checks data is currently retained for 400 days, then archived, and permanently deleted 10 days later. Once the new Actions retention behavior applies, a required check that has been archived may need to run again before a pull request can merge. The status checks reference is the place to confirm current check behavior.

Do not rely on an old green check as your only release or compliance record. Save the report that explains what was tested, and make the workflow easy to rerun from the same commit. A retained status tells you that a check existed; an archived report tells you what the check actually found.

A short preparation checklist

  1. Record the current retention value at repository, organization, and enterprise level.
  2. List the workflows whose history supports releases, incidents, or audits.
  3. Export important reports before October 1, especially for old releases.
  4. Set artifact retention per workflow where a shorter value is enough.
  5. Make release and test reports portable so they can be stored outside Actions.

For most repositories, no workflow change is required. The important change is knowing that your existing retention setting will soon cover more data. Review the value now, export the history that matters, and treat GitHub Actions retention as a working window rather than a permanent archive.