GitHub Actions History Shrinks on October 1—Archive Evidence Before It Vanishes

GitHub will shorten the available history for checks, workflow runs and statuses on October 1, 2026. According to GitHub’s August 27 announcement, those records will begin following the configurable Actions retention period already applied to artifacts and logs, rather than remaining available for more than 400 days; records beyond the configured window will be cleaned up automatically.

The change is scheduled but not yet active. Independent coverage published August 28 confirms the October 1 scope and the 90-day default. DevOps, security and compliance teams that require a longer audit, incident or metrics history therefore need to preserve the relationships among runs, commits, outcomes, logs and artifacts before GitHub removes the online records.

What becomes vulnerable to cleanup

The newly affected records are checks, workflow runs and statuses. Artifacts and logs already follow the configurable retention period, so the change brings all five categories under one setting at the repository, organization or enterprise level.

These categories are not interchangeable evidence. A workflow-run record establishes that automation ran and captures its result. Checks and statuses associate validation outcomes with a particular change, while logs and artifacts may contain the execution detail, test reports, scan results or release files needed to explain that outcome.

Saving only a downloaded log or artifact can consequently leave an evidentiary gap. A retained file is more useful when it remains tied to the repository, commit, workflow run, check result, timestamps and relevant deployment or release.

One setting now spans metadata and stored files

The shared setting creates a trade-off between the online investigation window and storage cost. GitHub classifies artifacts and logs as billable Actions storage, while checks, workflow runs and statuses are unbilled metadata. Raising retention preserves both groups longer, so keeping metadata available inside GitHub may also keep associated billable files for longer.

The default retention period is 90 days. GitHub’s organization settings documentation specifies a range of one to 90 days for public repositories and one to 400 days for private repositories; managed repositories and organizations cannot exceed a limit imposed at a higher level.

This makes the setting an operational window, not an unlimited compliance archive. Public repositories cannot retain the affected Actions history through this control for more than 90 days, and a private repository may have an organization or enterprise cap below 400 days.

Inventory evidence before selecting a retention period

A preservation decision should separate records by evidentiary purpose and storage treatment. The following inventory template distinguishes unbilled metadata from billable logs and artifacts while keeping the relationships needed for later review:

• Scope: organization, repository, workflow and accountable service owner.
• Run identity: workflow name, run ID, triggering event, branch or tag, commit SHA, actor, start time and completion time.
• Decision metadata: overall status and conclusion, relevant check names and outcomes, required-gate result, and any approval or deployment relationship needed for review.
• Execution evidence: selected job logs, error output and environment details required to explain a failure or reconstruct an incident timeline.
• Produced evidence: artifact names, file manifests, test or scan reports, checksums, and the release or deployment they support.
• Retention basis: audit obligation, incident-response lookback, delivery-metrics horizon, legal hold or no continuing requirement.
• Archive control: external location, access owner, planned deletion date, integrity method and restoration-test record.

The inventory also reveals where one retention value is too blunt. Routine branch runs may need only a short troubleshooting window, while production releases, security exceptions and material incidents may require a durable evidence package. Long-running delivery metrics generally depend on consistent run metadata, not every byte of every historical log.

Preserve a chain of evidence, not isolated downloads

Before October 1, identify repositories whose effective retention window is shorter than the organization’s audit, incident-response or measurement horizon. Records already older than that window deserve priority because cleanup begins when the expanded policy takes effect. A later setting increase cannot restore information that has already been removed.

For each run selected for preservation, store a machine-readable index with the necessary logs and artifacts. The index should connect the repository and commit to the run ID, trigger, timestamps, conclusion, checks or statuses, archived filenames and integrity values. It should also record the export time and the policy or requirement that justified retention.

Retrieval should not depend on a GitHub Actions page that may expire. An authorized reviewer starting with a release, incident or audit sample should be able to reach the relevant commit, automation outcome and supporting output from the archive. Access restrictions and deletion rules should reflect the sensitivity of the retained material.

Metrics pipelines need a separate inventory entry. If a delivery-frequency, failure-rate or recovery-time calculation queries historical workflow runs on demand, its source window will contract on October 1. Capturing the required fields on a schedule shorter than the configured retention period preserves the series without retaining every artifact solely for measurement.

What is settled before October 1

GitHub has fixed the effective date, the three newly covered record types and the use of the existing Actions retention hierarchy. It has also made clear that artifacts and logs remain billable, the newly governed metadata does not, and removed records cannot be recovered by extending retention afterward.

The unresolved decisions belong to each organization: which runs qualify as evidence, how long each evidence class must survive and whether GitHub’s permitted window is sufficient. Where it is not, the durable unit should be a linked package connecting the commit, run, decision metadata and necessary output—not an isolated log, artifact or screenshot.

Also read:

• Audit an AI Agent’s Memory Before a False Fact Becomes a Future Action
• Fast Business Internet Can Still Leave You Offline: Four Checks Before You Sign
• Free AI Can Accelerate a Long Report—If You Keep an Evidence Ledger