GitHub Actions Retention Changed on October 1: What CI/CD Teams Need to Audit Now

GitHub changed what its Actions retention setting controls on October 1, 2026. Checks, workflow runs and commit statuses are now deleted according to the same retention policy that already governs workflow artifacts and logs. Before the change, those records could remain available for 400+ days even when a repository used a much shorter Actions retention period.

For most teams, CI/CD keeps working normally. The risk is historical evidence: an engineering, support, audit or incident-response process may assume that old run metadata, third-party checks or deployment evidence will still be visible months later. Teams should therefore treat this as a data-retention review, not a pipeline migration.

This guide explains what changed, what can disappear, what does not need changing, and how to decide whether GitHub itself is the right long-term archive for CI/CD evidence.

What changed in GitHub Actions retention on October 1, 2026?

Checks, workflow runs and commit statuses now follow the configured GitHub Actions retention period, alongside artifacts and logs.

GitHub confirmed the change on October 1, 2026. The policy applies not only to checks produced by GitHub Actions but also to affected checks and statuses created by third-party applications.

GitHub's current repository Actions settings documentation says the default is 90 days. Public repositories can configure 1 to 90 days and private repositories 1 to 400 days, subject to organization or enterprise limits.

A repository configured for 30 days is therefore no longer merely saying “delete old artifacts and logs after 30 days.” It is also deciding how long affected run, check and status records remain available.

Does this break existing GitHub Actions workflows?

Normally, no. This is a retention change, not a workflow syntax or runner migration.

The immediate question is not whether tomorrow's build will execute. It is whether someone will need yesterday's CI/CD evidence after GitHub has deleted it.

Workflows worth reviewing include regulated or contractually audited releases, incident investigations that examine old deployments, flaky-test analysis over long periods, customer-support investigations, security processes relying on old third-party checks, and teams using workflow history as informal deployment evidence.

If none of those processes needs history beyond the configured period, a separate archive may be unnecessary.

What should a team audit first?

Start with the retention setting, then map every business process that depends on historical CI/CD records.

repository
→ retention period
→ organization / enterprise cap
→ workflow
→ evidence produced
→ who uses it
→ required history
→ system of record
→ archive required?

1. Check repository retention

GitHub documents the repository setting under:

Repository
→ Settings
→ Actions
→ General
→ Check, workflow run, status, artifact and log retention

Do not assume every repository has the same effective value. Organization and enterprise policies can cap repository retention.

2. Check organization and enterprise policy

GitHub also supports retention configuration at organization and enterprise levels. For multi-repository products, this is where configuration drift can become important: one service may preserve months of evidence while another removes it after weeks.

3. Identify third-party checks and statuses

The expanded policy is not limited to GitHub Actions-generated data. GitHub explicitly says affected checks and statuses from third-party applications are also covered.

Ask a precise question: does any engineering or governance process use GitHub's check/status history as the only surviving record of what an external system reported? If yes, verify whether that external service has its own durable history.

What data should you archive outside GitHub?

Archive evidence that has a real retention requirement. Do not copy every CI log forever by reflex.

The goal is not maximum retention. The goal is intentional retention.

If a record must survive platform configuration changes, repository deletion, account changes or a longer contractual period, store the authoritative copy in a system designed for that requirement.

How should long-term CI/CD evidence be stored?

Keep GitHub as the execution and collaboration layer, and move long-lived evidence to a separate durable store when the retention requirement exceeds GitHub's role.

GitHub Actions
    ↓
build / test / security / deploy
    ↓
produce durable evidence
    ↓
object storage or evidence system
    ↓
immutable identifier + release metadata
    ↓
retention / lifecycle policy

A release workflow might preserve commit SHA, workflow/run identifier, application version, environment, deployment timestamp, test summary, SBOM or provenance, artifact checksum, and an approval or change-ticket reference.

The archive should not depend on a human remembering to download a log before it expires.

If your deployment process has grown into scripts with unclear ownership, Softotic's custom software development service can help turn release evidence and operational workflows into an explicit system rather than another manual checklist.

Should you simply increase GitHub retention to 400 days?

Only if the repository is eligible and longer GitHub history actually solves the requirement.

For private repositories on GitHub.com, GitHub documents a configurable range up to 400 days, subject to organization and enterprise caps. Public repositories have a maximum of 90 days.

GitHub notes in its August announcement that artifacts and logs count toward billable Actions storage, while checks, workflow-run and status metadata do not. A longer shared retention setting can therefore retain billable artifacts and logs for longer.

Before raising retention globally, ask which records need longer history, whether GitHub should be the system of record, whether raw artifacts and logs need the same lifespan, and whether a targeted archive is more appropriate.

Can individual artifacts use a different retention period?

Yes. GitHub supports a custom retention period for individual workflow artifacts, within applicable repository, organization and enterprise limits.

GitHub's artifact documentation also notes that the REST API exposes an __INLINE_CODE_0__ value for artifacts.

That is useful when one workflow creates disposable debugging output and a release artifact that deserves longer retention. But artifact-specific retention does not make every related run/check/status record a permanent audit trail.

What happens to data that has already been removed?

Changing retention does not restore records GitHub has already deleted.

GitHub states this in its October 1 announcement. The safe sequence is therefore:

1. inspect the effective retention setting;
2. identify history that is still available;
3. export anything with a genuine longer-term requirement;
4. adjust retention where appropriate;
5. implement durable archiving for future evidence.

Waiting until an incident months later is not a recovery strategy.

A practical retention decision framework

GitHub-only history

Use GitHub alone when historical data is useful but not critical after the configured period, such as routine CI logs, temporary test output and ordinary workflow history.

Longer GitHub retention

Use a longer GitHub window when engineers genuinely benefit from it and repository type, organization policy and storage implications are acceptable. Examples include long debugging cycles, intermittent test failures and support investigations that regularly cross a 90-day boundary.

External durable archive

Use an external archive when evidence has a lifecycle independent of GitHub, such as signed release evidence, provenance or SBOM retention, regulated audit evidence, long-term deployment records, or contractual retention obligations.

This classification is more useful than choosing one retention number for every repository.

GitHub Actions retention audit checklist

• □Record the effective retention period for each important repository.
• □Check organization and enterprise caps.
• □Identify workflows whose history is used after releases.
• □Identify third-party checks and commit statuses.
• □Determine whether another system already stores the evidence.
• □Separate disposable logs from durable release evidence.
• □Export still-available historical evidence if required.
• □Decide whether to increase GitHub retention.
• □Account for artifact/log storage implications.
• □Add external archival where GitHub should not be the system of record.
• □Test that archived evidence can actually be retrieved.
• □Document ownership and retention requirements.

For teams maintaining multiple applications, this can be folded into a broader web application development and maintenance workflow, rather than handled repository by repository after evidence disappears.

FAQs

What is the default GitHub Actions retention period?

GitHub documents a default of 90 days for checks, workflow runs, commit statuses, artifacts and logs on GitHub.com.

When did checks and workflow runs start following Actions retention?

The expanded policy took effect on October 1, 2026. GitHub confirmed the rollout that day.

Does GitHub Actions retention affect third-party status checks?

Yes. The policy covers affected checks and commit statuses created by third-party applications as well as GitHub Actions.

Can public repositories retain Actions history for 400 days?

No. GitHub documents a maximum of 90 days for public repositories on GitHub.com. Private repositories can be configured up to 400 days, subject to higher-level caps.

Will increasing retention restore deleted workflow history?

No. GitHub says changing the setting does not restore data already removed by a retention policy.

Does longer retention increase GitHub Actions storage cost?

It can. GitHub says artifacts and logs count toward billable Actions storage, while check, workflow-run and status metadata do not. Increasing the shared retention period can therefore keep billable artifacts and logs for longer.

Sources and references

• 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 retention for an organization
• GitHub Docs: Removing workflow artifacts