GitHub Actions History Starts Expiring on October 1: What Disappears and What to Archive

Short answer: starting October 1, 2026, GitHub will stop keeping checks, workflow runs, and commit statuses for 400+ days regardless of a repository's Actions retention setting.

Those records will instead follow the same retention period already used for Actions artifacts and logs. The default is 90 days. Public repositories can configure up to 90 days; private repositories can configure up to 400 days, subject to organization or enterprise caps.

For most projects, that is fine. For teams that use old workflow runs as release evidence, incident-response history, audit material, or debugging context, it is a real data-retention change worth reviewing before October.

Policy check: August 30, 2026. GitHub announced this change on August 27 and says it begins October 1, 2026. The current documentation still lists 90 days as the default Actions artifact/log retention period.

What changes on October 1

Today, GitHub Actions has effectively had two different retention behaviors:

• artifacts and logs follow the repository, organization, or enterprise Actions retention setting;
• checks, workflow runs, and statuses have been retained for 400+ days regardless of that setting.

From October 1, GitHub says all five will be governed by one setting:

checks
workflow runs
statuses
artifacts
logs
        ↓
Actions retention setting

GitHub also says the setting label in the interface will change to reflect the wider scope.

The important part is not the new label. It is that a repository configured for 30 days will no longer keep its workflow-run history for more than a year while deleting only the associated logs and artifacts. The run/check/status records themselves will also age out.

The retention limits by repository type

For public repositories, this is especially simple: 90 days becomes the maximum GitHub-native retention window for these Actions records. If older workflow evidence matters, it needs to exist somewhere else.

What exactly can disappear?

GitHub's August 27 announcement names three metadata classes that are newly affected:

Workflow runs

The historical run records for Actions workflows will be cleaned up once they exceed the configured retention period.

That means GitHub should no longer be treated as an indefinite history of every CI/CD execution.

Checks

Checks associated with commits and pull requests will follow the same retention policy.

If an old release or incident depends on proving which checks ran and what their result was, keeping only the Git commit is not the same as keeping the check history.

Commit statuses

Statuses will also age out under the same setting.

This matters for systems that use status contexts as evidence of what passed at a particular point in time.

Artifacts and logs already follow the retention setting, so the October change mainly removes the mismatch where metadata remained long after the detailed execution data had expired.

What does not become billable just because it is retained?

There is an important billing distinction.

GitHub says checks, workflow runs, and statuses metadata are not billed as Actions storage.

Artifacts and logs are different: they count toward Actions storage. So raising retention to keep workflow history longer can also keep the associated artifact/log data longer, which can increase storage usage and cost.

That creates a slightly awkward trade-off:

The metadata you want may be free, but the single retention control can also preserve data that costs money.

For private repositories, teams should therefore avoid solving every audit requirement by automatically setting everything to 400 days.

A simple way to estimate the storage effect

For a steady workflow that generates roughly the same amount of retained data every day, stored volume is approximately proportional to the retention window.

If a repository creates 1 GB of retained artifacts/logs per day:

*A planning approximation only. Actual usage depends on deletions, artifact sizes, workflow frequency, compression, plan allowances, and GitHub's billing model.

The useful formula is:

average retained data per day × retention days
≈ steady-state retained volume

So moving from 30 to 90 days can roughly triple steady-state storage for a stable workload. Moving from 90 to 400 days can increase it by more than four times.

That is why the better question is not “What is the maximum retention?” but “Which evidence really needs to live inside GitHub for this long?”

Who should care most?

Release engineering teams

If production releases depend on proving which workflow ran, which commit was built, and which checks passed, a 30- or 90-day history may be too short for quarterly or annual investigations.

Security and incident-response teams

GitHub's own security documentation notes that Actions logs can be useful during incident investigation. If an incident is discovered months later, expired workflow data cannot be reconstructed simply by increasing the retention setting afterward.

Regulated or audited teams

Some organizations need evidence that a build, approval, test, or deployment control occurred. GitHub Actions history can help operationally, but it should not be the only archive if the required retention period exceeds the platform setting.

Maintainers of public projects

Public repositories have the tightest ceiling: 90 days maximum. Projects that want years of reproducibility or release evidence need an external archive by design.

Teams that rarely inspect old CI

If old workflow history is almost never used, the change may be beneficial. Lower retention keeps stale Actions data out of the interface and can reduce billable artifact/log storage.

GitHub explicitly says most repositories do not need to take action.

The key mistake: increasing retention after the data is gone

GitHub says adjusting retention does not restore data that has already been evicted.

So this is not a setting to revisit only after an incident.

A team that discovers in December that it needed an August workflow log cannot set retention to 400 days and bring that run back.

The preservation decision has to happen before the relevant records expire.

A practical retention framework

Instead of choosing one number for every repository, classify workflow history into three buckets.

1. Disposable CI history

Examples:

• routine branch tests;
• dependency-update runs;
• preview builds;
• repeated failed experiments.

These usually do not need long retention. A shorter window can keep GitHub cleaner and reduce storage.

2. Operationally useful history

Examples:

• main-branch builds;
• release-candidate validation;
• production deployment runs;
• security scans tied to a shipped version.

These may deserve the repository's normal 90-day window or longer in private repositories.

3. Evidence that must outlive GitHub Actions retention

Examples:

• signed release manifests;
• compliance evidence;
• security incident records;
• long-lived deployment attestations;
• artifacts required for reproducibility;
• records needed beyond 90 days in a public repository.

These should be exported to durable storage rather than relying on GitHub's Actions history indefinitely.

What should be archived?

A useful archive is more than a screenshot of a green checkmark.

For important runs, preserve enough information to answer:

1. What commit ran?
2. Which workflow/version executed?
3. When did it run?
4. What was the conclusion?
5. Which artifacts were produced?
6. Which logs or evidence are needed to explain the result later?

Depending on the project, that can mean storing:

• the workflow-run ID and URL;
• repository and commit SHA;
• workflow file or workflow revision;
• run conclusion and timestamps;
• release artifacts;
• workflow logs;
• test reports;
• provenance/attestation data;
• deployment identifiers.

Do not archive secrets or sensitive log content simply because storage is available. Logs should still follow the project's security and data-handling rules.

How to export before expiry

GitHub provides official ways to retrieve both run logs and artifacts.

Download artifacts with GitHub CLI

For a specific run:

gh run download <run-id>

A specific artifact can be selected with:

gh run download <run-id> -n <artifact-name>

The CLI extracts the artifact contents locally, so a production archive process should then move the relevant files into whatever durable store the project actually controls.

Download logs through the REST API

GitHub's Actions REST API provides a workflow-run logs endpoint:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

GitHub returns a temporary redirect URL for the archive. The documented redirect link expires quickly, so an archiver should download the file immediately rather than storing the temporary URL.

List and download artifacts through the REST API

The Actions artifacts API can list artifacts for a repository or workflow run and download them individually.

That makes it possible to automate a policy such as:

When a production deployment succeeds, copy the run metadata, logs, and release artifacts to the long-term release archive.

That is usually better than retaining every CI artifact for 400 days merely because a small subset is important.

A five-minute audit before October 1

Step 1: check the current retention value

In a repository, go to:

Settings → Actions → General → retention

GitHub says the label will broaden as the October change rolls out, but the underlying retention control already exists.

Step 2: identify the oldest workflow history that is genuinely useful

Look at the last incident, rollback, audit, or release investigation. How far back did the team actually need to go?

If the answer is “we needed a run from eight months ago,” a 90-day plan is not enough.

Step 3: check whether a higher-level policy caps the repository

Organization and enterprise settings can limit repository retention. A repository owner may not be able to raise the number independently.

Step 4: decide what stays in GitHub and what gets exported

A reasonable default pattern is:

Step 5: automate preservation for future critical runs

Manual archiving works once. A workflow or release process that automatically exports the right evidence is much safer.

The goal is not “save everything forever.” It is make long-term retention intentional.

Should private repositories just set 400 days?

Sometimes, but not automatically.

A 400-day setting is reasonable when:

• year-long GitHub-native history is genuinely useful;
• storage volume is low;
• the organization accepts the storage cost;
• there is no stronger external evidence system.

It is weaker when:

• large build artifacts are produced constantly;
• only release workflows need long history;
• the retention requirement is longer than 400 days anyway;
• compliance requires an archive independent of the CI platform;
• teams are keeping data only because nobody has defined what can be deleted.

For many organizations, 90 days in GitHub plus selective durable archiving is a cleaner architecture than 400 days for every artifact and log.

What is confirmed, and what should not be assumed

Confirmed by GitHub

As of August 30, 2026:

• the change starts October 1, 2026;
• checks, workflow runs, and statuses will follow the Actions retention setting;
• those records previously remained for 400+ days regardless of that setting;
• the default retention period is 90 days;
• public repositories can retain Actions artifacts/logs for 1–90 days;
• private repositories can retain them for 1–400 days;
• public repositories will have a 90-day maximum for the newly covered checks/runs/statuses;
• checks, workflow-run, and status metadata are not billed as storage;
• artifacts and logs can contribute to billable Actions storage;
• changing retention cannot restore data that has already been deleted.

Do not assume

• that every old record disappears exactly at midnight on October 1;
• that increasing retention after an incident can recover expired history;
• that an old pull-request page is a permanent audit archive;
• that the highest retention value is automatically the cheapest or safest choice;
• that public repositories can keep Actions history inside GitHub for more than 90 days through this setting.

What to watch next

The main thing to watch is the rollout behavior after October 1: how quickly GitHub cleans existing records that are already older than each repository's configured retention period, and how the updated interface surfaces expired check/run history.

Teams with strict evidence requirements should not wait for that behavior to become visible before building an archive. The platform contract is already clear enough: Actions history is becoming retention-bound rather than quasi-permanent.

Conclusion

GitHub's October change is small in the settings UI but meaningful for anyone who treats Actions as long-term operational history.

From October 1, checks, workflow runs, statuses, artifacts, and logs all age out according to the same Actions retention policy. For public repositories, 90 days is the ceiling. Private repositories can go higher, but longer retention can also keep billable artifacts and logs around for longer.

The practical response is straightforward:

1. check the retention value now;
2. decide which runs actually need long-term evidence;
3. keep routine CI on a sensible GitHub retention window;
4. export critical release, security, or compliance evidence before it expires.

GitHub Actions is a CI/CD system. After October 1, it should no longer be mistaken for a permanent archive.

Sources

Checked August 30, 2026:

• GitHub Changelog — Actions retention will cover checks, workflow runs, and statuses
• GitHub Docs — Managing GitHub Actions settings for a repository
• GitHub Docs — Configuring Actions retention for an organization
• GitHub Docs — GitHub Actions billing
• GitHub Docs — REST API endpoints for workflow runs
• GitHub Docs — REST API endpoints for Actions artifacts
• GitHub CLI — gh run download