GitHub Actions retention is now about more than downloadable build files. On October 1, 2026, GitHub confirmed that checks, workflow runs and commit statuses also follow the retention setting used for artifacts and logs. For a small development team, the useful question is not “how do we keep everything forever?” It is “which evidence will we need to explain this release after its workflow history expires?” This guide separates retention from search-result limits and offers a manageable release-evidence checklist.
Sources checked October 5, 2026. This article was prepared with AI assistance and editorial review from the primary documentation linked below. It is source-based analysis, not a hands-on test of GitHub’s cleanup behavior. The proposed worksheet and archive inspection have not been performed by TechPulse. This is an operational guide, not a legal-compliance or security certification.
What the October 1 retention change covers
GitHub’s October 1 announcement says the expanded policy applies on github.com. Checks and statuses from third-party applications are included, not only records created by Actions. Repository settings remain constrained by organization and enterprise caps; public repositories have a maximum of 90 days. A longer setting does not restore records already removed.
That makes a workflow link a useful reference, but not a permanent release record. Our recommendation is to keep the evidence you deliberately select in a separately managed archive, with its own access and retention rules. Do not assume this announcement describes the behavior of every GitHub Enterprise Server installation.
Missing results do not always mean the same thing
Two September changes matter when investigating an apparently incomplete history. On September 24, GitHub stopped showing expired artifacts in run summaries and the relevant REST API responses. The former expired marker could remain after the underlying file was gone. This is a visibility change, not a new artifact-retention or billing rule. Artifact names may still be identifiable from logs while those logs remain available; that is not recovery of the artifact files.
Separately, the September 25 query update reports a “2,500+” count when a matching workflow-run search exceeds that threshold. The announcement still describes paginated results of up to 1,000 items. Neither number is a promise that a broad query exports all history.
The workflow-runs API reference documents a 1,000-result search limit for filters including actor, branch, creation time, event, commit and status. Pages have a maximum of 100 results. For an inventory, use narrower creation-time windows, record the filters and follow pagination within each window. If a window still reaches the search boundary, split it again; deduplicate overlapping results by run ID. Treat authentication, repository selection and filter mistakes as separate diagnostic possibilities rather than immediately declaring data deleted.
Read the effective setting before changing it
Start with a read-only settings review. In the repository, open Settings, then Actions and General. Find the combined retention control and record its current value, repository visibility and any governing organization or enterprise limit. GitHub’s repository settings documentation describes a default of 90 days, a public range of 1–90 days and a private range of 1–400 days, subject to applicable caps.
That documentation also says a customized retention period applies to new objects, not retroactively to existing ones. Do not present a settings increase as backfilling old records or extending every existing object. Individual artifacts can have their own custom retention period; do not assume the repository number alone answers every artifact’s expiry question.
Choose a period from an actual workflow need: delayed bug reports, release support, incident investigation or a team’s approved evidence policy. Ask the responsible maintainer to approve changes. Keeping more data also creates more information to manage; “set the maximum” is not automatically the best operational choice.
Build a small release-evidence record
Use this proposed worksheet for one real release before designing a fleet-wide export. It is an editorial recommendation, not an official GitHub requirement. The aim is to let a colleague answer what was built, from which source, and what was checked without depending entirely on an old workflow URL.
| Record | Question it should answer |
|---|---|
| Release and source identity | Which repository, version, tag and exact commit were intended? |
| Workflow identity | Which workflow file, run ID and attempt produced the reviewed output? |
| Selected output | Which package or report was retained, with what filename and locally calculated checksum? |
| Review decision | Who reviewed it, when, and what unresolved limits were recorded? |
| Archive ownership | Where is the record, who may read it, and when should it be reviewed or removed? |
A checksum identifies bytes for later comparison; it does not establish that the software is safe or that an approval was valid. Preserve relevant context with the file rather than treating an isolated hash as a complete provenance record. For npm maintainers, this complements our staged-release review guide: inspecting the actual package and retaining an understandable decision are different responsibilities.
Export deliberately, then inspect the archive
Download only the available logs and outputs that serve the chosen purpose. The workflow-runs API documents a logs-download redirect whose link expires after one minute. Keep the resulting approved files when appropriate, not a temporary download URL as if it were an archive.
Before copying build logs into a shared location, review them for credentials, personal information, private repository paths and customer data. Redact or restrict sensitive material through your team’s process. Do not publish logs in a public issue just to make them easy to find, and do not grant broad write permissions to an exporter that only needs to read selected records.
Our proposed inspection is straightforward: have an authorized colleague open the saved record from the archive, confirm that the intended files are present, compare recorded identities and explain any missing context. Inspect unfamiliar build archives without executing their contents. Record the date and outcome when your team actually performs this check; TechPulse has not executed it. An archive that nobody can locate or read is not useful merely because a download once succeeded.
A practical checklist for this week
- Pick one release workflow. Start where a missing report would cause a concrete support problem.
- Record the current retention controls. Include governing caps and any artifact-specific choices; keep settings review separate from changing settings.
- Locate one recent, still-available run. Note its source commit, run ID and attempt, not only a screenshot of a green check.
- Select the evidence. Retain what explains the release, review sensitive content and document the archive’s access rules.
- Check retrieval. Ask an authorized colleague to find and understand the record before relying on the process.
- Assign an owner. Schedule a proportionate review rather than creating an unattended export that silently fails.
The distinction is simple: retention decides what remains on GitHub; search limits affect what a query reveals; a release archive preserves the evidence your team intentionally chooses. Document those boundaries before changing settings or promising that every historic run can be recovered. Our editorial policy explains why this guide distinguishes documented behavior from unperformed testing.
✍️ Leave a Comment