GitHub Actions Retention Now Deletes Checks, Runs and Statuses: What Teams Must Archive

If your team has treated old green checkmarks as permanent records, now is the time to check your settings.

What changed on October 1​

GitHub first announced this on August 27. Until now, checks, workflow runs, and statuses were retained for 400+ days regardless of your retention configuration. After this change, they will automatically be cleaned up once they pass the artifact and log retention period configured for your repository, organization, or enterprise.

GitHub's stated reason is housekeeping. The August announcement says the change reduces stale data stored across GitHub Actions and helps keep checks, workflow runs and statuses fast and reliable.

The main points of the change:

• One setting now controls five types of data. Its label in the UI now reads "Check, workflow run, status, artifact and log retention."
• The default is unchanged. GitHub's documentation says that by default, checks, workflow runs, commit statuses, and the artifacts and log files generated by workflows are retained for 90 days before they are automatically deleted.
• Third-party data is included. These retention policies apply to checks data, including check suites and check runs, and to commit statuses, including those created by third-party integrations. The policies are not limited to data created by GitHub Actions. Statuses posted by an external CI service, code scanner or deployment bot are covered too.
• Platform scope: GitHub says the expanded policy applies to GitHub Actions on github.com. Nothing in the announcements covers GitHub Enterprise Server, and you shouldn't assume it applies there.

Summary: A setting that used to affect storage costs now also decides how long your CI history is visible.

The limits: public vs. private, and who sets the cap​

The allowed range depends on whether the repository is public or private:

Settings at higher levels act as caps. For managed repositories and organizations, the maximum retention period cannot exceed the limit set by the managing organization or enterprise. A repository admin can't set a value above the organization's limit, and an organization owner can't exceed the enterprise's.

For public repositories, the August changelog says the 90-day maximum for checks, workflow runs and statuses matches the existing limit for artifacts and logs. Open-source projects can't raise this. Run history older than about three months will disappear on public repos.

Summary: Private repos can keep this data for up to 400 days if every level above allows it. Public repos are limited to 90 days.

What you can't get back​

Two points are easy to get wrong:

1. Changes aren't retroactive. GitHub's docs say that when you customize the retention period, it only applies to new checks, workflow runs, commit statuses, artifacts, and log files, and does not retroactively apply to existing objects.
2. Deleted data stays deleted. The October 1 changelog says changing the setting won't restore data that was already removed. The August post notes that artifact and log retention already worked this way.

Raising the setting to 400 days next month won't bring back runs that were purged this week. It only affects how long future records are kept.

Summary: Retention controls the future, not the past. Anything you need from before today's cleanup had to be archived beforehand.

Why this matters more than it sounds​

A workflow run isn't just a log file. GitHub's documentation explains that Actions uses the Checks API to report statuses, results and logs. GitHub creates a check suite for each workflow run, and that suite contains a check run for each job. So this change covers the records that link a commit to the result of its pipeline.

Several outside writers have looked at the effects:

• Release and audit evidence. DevOpsBoys argues that 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. Its conclusion is that the retention setting is now an operational and compliance decision, not just a storage-cost control.
• Supply-chain provenance. A DEV Community post points out that npm provenance, GitHub artifact attestations and the SLSA generators all embed a run ID, and verification points back to that run's page on GitHub. The author adds that those runs already expired after 400+ days. The new rule shortens that window for many repositories.
• Engineering metrics. Microsoft's Tech Hub DevOps roundup flagged teams that rely on long-lived history for audits, incident timelines, or DORA-style reporting as the ones that should review retention and export plans.

GitHub says that for most repositories no action is required. That's probably true for a weekend side project. It's less true for a regulated shop where an auditor may ask what passed CI before a release eleven months ago.

Summary: The deleted metadata records what ran, against which commit, and whether it passed. For release audits, incident reviews and provenance checks, that history can matter as much as the logs.

Billing: what costs money and what doesn't​

GitHub separates the two kinds of data. Checks, workflow run, and statuses metadata are not billed for storage, but the artifacts and logs associated with them are.

Because one setting controls both, you face a trade-off:

• Lowering your retention period removes artifacts and logs sooner, which can reduce your Actions storage costs.
• Raising your retention period keeps artifacts and logs available longer, which may increase your billable Actions storage.

You can't keep the free metadata for 400 days while deleting the billable artifacts after 30. If you want a long online history, you pay to keep artifacts and logs just as long. The August announcement also says that repositories that kept artifacts and logs longer than their configured setting may see their billable storage drop.

Summary: A longer history costs storage. Either pay to keep everything online longer or archive the metadata somewhere else.

How to review your retention setting​

GitHub documents this path for organizations:

1. On GitHub, go to the organization's main page.
2. Under the organization name, click Settings. If you can't see the tab, open the dropdown menu and click Settings.
3. In the left sidebar, click Actions, then General.
4. Under Check, workflow run, status, artifact and log retention, enter a new value.
5. Click Save.

You'll know it worked when the field keeps your new value after saving. If GitHub won't accept a number, it's probably above the cap set at a higher level, so ask whoever manages the enterprise. Keep in mind that the new value only applies to records created from now on.

When you review, check these:

• The repository's own setting. Repository retention can be changed in repository settings, within the caps above it.
• Organization and enterprise caps. A generous repository value doesn't help if the cap above it is lower.
• Public or private. Public repositories stop at 90 days.
• Who needs the history. Ask your release, security, compliance and SRE teams how far back they actually look.
• Third-party integrations. If an external tool posts statuses to commits, those statuses now expire on the same schedule.

Summary: Check the setting at every level, compare it with how far back each team actually needs, and remember that a new value only applies going forward.

Archiving: plan for it yourself​

GitHub's advice for longer retention is to export or archive anything you need beyond your configured period. The DEV Community author complains that there is no export button. Teams will have to build their own process using the APIs or a community tool.

One example is the open-source actions-attic project. It describes itself as keeping a plain-text archive of a repository's workflow runs, check runs and commit statuses inside the repository, on a separate git ref. It has limits: this archives the run, check and status metadata, not log text or artifacts. Its own notes say the backfill only reaches as far back as GitHub still has data. This is a third-party project, not an official GitHub feature, so review it as you would any code that touches your repositories.

Whatever you use, Quasa.io makes a good point: a saved log or artifact is more useful when it stays linked to its repository, commit, workflow run, check result and timestamps. A downloaded log with no record of which commit produced it is weak evidence.

Summary: If records must outlive the retention window, archive them on a schedule and keep each one linked to its commit and run.

Bottom line​

This change is about the data's lifecycle, not about what Actions can do. It's still significant. GitHub now applies one rule to everything Actions produces, which is consistent and likely easier on GitHub's systems. The catch is that your CI history is now tied to a setting many teams have never opened.

For public repositories, assume three months of history. For private ones, check every level of the setting, decide whether storage costs or an archive pipeline is the better option, and remember that records already removed can't be recovered.