Since October 1, 2026, the GitHub Actions retention setting on github.com also governs check data, workflow runs, and commit statuses, alongside artifacts and logs. GitHub says these records are cleaned up when they pass the period set at the enterprise, organization, or repository level. Checks and statuses from third-party apps are included, and changing the setting will not restore records already removed. GitHub’s October 1 notice confirms the change is live; the August announcement, clarified September 15, explains what changed.
If a release review, incident investigation, or audit needs evidence beyond the GitHub window, check what is still available and export the pieces you need before they disappear. Raising a retention number is not the same as making an archive.
Check the value and the limit above your repository
At repository level, open Settings → Actions → General → Check, workflow run, status, artifact and log retention. An organization or enterprise can set a maximum that the repository cannot exceed. GitHub’s documentation lists a 90-day default, a 1-to-90-day range for public repositories, and a 1-to-400-day range for private repositories, subject to the managing organization’s or enterprise’s cap. The value you can actually use may be lower than the private-repository maximum.
You can read the configured value through GET /repos/{owner}/{repo}/actions/permissions/artifact-and-log-retention. Its response has days and maximum_allowed_days. GitHub’s example response uses 90 and 365; those are example values, and 365 is not the universal private-repository maximum. The REST route keeps the older “artifact and log” wording, though the same setting now covers checks, workflow runs, and statuses. This specific settings endpoint requires authentication: a fine-grained token needs repository Administration: read, while a classic personal access token or OAuth token needs the repo scope. For run and artifact inventory, use Actions: read; for check data and annotations, Checks: read; and for commit statuses, Commit statuses: read. Some public-data endpoints allow unauthenticated reads where their documentation says so; that exception does not apply to this settings endpoint. See the repository retention settings endpoint and GitHub’s repository settings guide.
There is a date wrinkle in the documentation. The settings page still contains an “Starting October 1” warning, even though that date has passed; GitHub’s October 1 changelog confirms the rollout is now effective on github.com. The same settings page says a custom retention value applies only to new objects, not existing ones. Do not assume that raising the value today will extend older records. Export any older evidence you still need, and treat a changed setting as protection for new objects. GitHub also says a setting change cannot restore data already deleted.
The October 1 changelog names github.com. If you use GitHub Enterprise Server or another deployment, check the documentation for that product and version rather than assuming the same rollout date.
Map the record types before exporting
A workflow run page is only one part of CI history. A useful archive keeps the record that links a result to a commit, plus any logs, annotations, or artifact bytes the investigation needs.
| Record | Read-only API route | What to preserve and where coverage stops |
|---|---|---|
| Workflow runs and attempts | GET /repos/{owner}/{repo}/actions/runs?per_page=100&created=START..END | Save each run ID, current run_attempt, workflow path or ID, event, commit SHA, timestamps, conclusion, actor, and URL. The run list describes the latest attempt; it is not an archive of every rerun log. For each earlier attempt you need and have identified, download its ZIP from GET /repos/{owner}/{repo}/actions/runs/{run_id}/attempts/{attempt_number}/logs. The attempt-log endpoint returns a temporary download redirect. |
| Check suites and check runs | GET /repos/{owner}/{repo}/commits/{ref}/check-suites?per_page=100, then /check-suites/{check_suite_id}/check-runs?filter=all&per_page=100; when annotations matter, /check-runs/{check_run_id}/annotations?per_page=100 | Keep suite and run IDs, app, status, conclusion, output, and annotations when they matter. The check-run list for a ref defaults to filter=latest; use filter=all for older versions. The separate annotations endpoint is paginated and uses Checks: read. |
| Commit statuses | GET /repos/{owner}/{repo}/commits/{ref}/statuses?per_page=100 | Save each status state, context, description, creator, timestamps, and target URL. A target URL may point to logs held by another CI provider, which needs its own export. |
| Artifacts | GET /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts?per_page=100, then /actions/artifacts/{artifact_id}/zip | Save the ZIP bytes and the artifact ID, name, size, digest, creation time, and expires_at. Do not keep only the download URL. |
| Workflow logs | GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs or /attempts/{attempt_number}/logs | Download the log archive itself. The API responds with a redirect URL that expires after one minute, so follow it immediately. |
| Actions caches | Separate cache settings and cache APIs | Caches do not use the new five-item retention setting. Their default inactivity window and storage eviction rules are separate; a dependency cache is not a durable test-evidence archive. |
The main run, check, status, artifact, and log endpoints are documented in GitHub’s workflow-runs API, check-suites API, check-runs API, commit-statuses API, and artifacts API. These endpoints return different objects; there is no single run-list response that includes every check, external status, log file, and artifact byte.
Use a read-only export plan that can show its gaps
Read the setting and save a bounded run inventory
This Bash example uses GitHub CLI for two documented read-only requests. Before using it, confirm gh is authenticated to an account authorized for the intended repository, for example with gh auth status. Use a fine-grained token with Administration: read for the retention setting and Actions: read for workflow runs. If you use a classic token, the repository settings endpoint requires repo. Replace the owner, repository, start, and end placeholders. Use ISO 8601 UTC timestamps for the bounded created range. The commands were not run against a repository.
set -eu
umask 077
OWNER='OWNER'
REPO='REPO'
START='YYYY-MM-DDTHH:MM:SSZ'
END='YYYY-MM-DDTHH:MM:SSZ'
OUT="ci-history-export-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -m 700 "$OUT"
cd "$OUT"
gh api --method GET \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"/repos/$OWNER/$REPO/actions/permissions/artifact-and-log-retention" \
> retention.json
gh api --method GET \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"/repos/$OWNER/$REPO/actions/runs?per_page=100&created=$START..$END" \
--paginate --slurp \
> workflow-run-pages.jsonThe settings response contains days and maximum_allowed_days; the numbers shown in GitHub’s schema example are not values from your repository. The run output is an outer JSON array of page objects, each with its own workflow_runs results. --paginate follows the REST pagination links, and --slurp keeps the page objects together in that array. This gives you run metadata only. It does not fetch earlier-attempt logs, artifact ZIPs, check annotations or commit statuses; use the relevant rows above for those records. The GitHub CLI manual documents the method, pagination, and slurp options.
- Write down what the evidence is for. Name the consumers, the longest time they need access, and the record types they will need. For a release review that may mean the run attempt, commit SHA, check result, test report artifact, and logs. For a longer audit window, ask the owner of that requirement to set the retention rule. GitHub’s maximum is a platform limit, not proof that the period meets a legal or internal policy.
- Record the effective setting and its cap. Read the repository, organization, and enterprise policy that governs the repository. Keep the date, value, and maximum allowed value with the export manifest. Avoid the matching
PUTsettings route unless you are explicitly changing policy. - Enumerate runs in date ranges. Set
per_page=100; the CLI example above follows pagination automatically, while a direct REST client must follow the response’sLinkheader. GitHub caps a filtered workflow-run search at 1,000 results. Check the returnedtotal_count, number of page objects, and date-window boundaries; reaching ten pages by itself proves neither that the window was complete nor that more results were hidden. Subdivide any window that reaches or approaches the cap and record the resulting ranges and page counts. See GitHub’s workflow-run listing reference. - Walk checks by commit. For each relevant commit SHA, list its check suites, then list every suite’s check runs with
filter=all. The shortcut endpoint for check runs on a ref uses the latest filter by default and can stop at the 1,000 most recent suites on one ref. GitHub recommends listing suites and then the runs for each suite when broader coverage is needed. The checks API is scoped to pushes in the repository where the suite or run was created, so account for forked repositories separately. - Read statuses and artifacts separately. Statuses are returned newest first for the requested ref. Page through them, then download each unexpired artifact ZIP you need. The artifact object exposes an expiry time and digest, but its listing is not the artifact’s content.
- Fetch expiring downloads immediately. Both workflow-log and artifact downloads use temporary redirects that expire after one minute. Automate the redirect and file download in one operation, then verify the saved bytes. Do not store the temporary URL as if it were a permanent archive link.
- Bind the files to a manifest. Record repository URL and ID, relevant commit SHAs (including commits with third-party checks even when there is no Actions run for them), workflow path, run ID and each required attempt, check suite and run IDs, annotation pages, status context, artifact IDs and digests, request date, API route, pagination ranges, and a SHA-256 hash for every downloaded file. Store the manifest, JSON responses, log ZIPs, and artifact ZIPs in a location with the access controls and retention your organization requires. Test retrieval and compare hashes before relying on the archive.
When a read fails: Pause and inspect the endpoint’s documented permission, access policy, and any rate-limit details before changing credentials. A 403 or rate-limit response calls for diagnosis, not a broader token by default. For a 404, verify the repository path, record ID, access, and object state; do not assume it proves deletion or that data can be restored. The artifact-download endpoint documents 410 Gone; if returned, treat that download as unavailable through this API. Check artifact metadata such as expired when available, and do not promise a restore. GitHub documents these responses in the artifact-download reference and its REST rate-limit guidance.
Use the least privilege needed for the read: fine-grained tokens use Actions: read for runs, logs, and artifacts; Checks: read for check suites and runs; and Commit statuses: read for statuses. Classic tokens for private repositories may require the broader repo scope. Check the endpoint’s permission table before creating a token.
A normal source-code mirror is not a complete Actions export. Workflow, check, status, log, and artifact records use separate API routes, so preserve the responses and file contents required for the investigation, release review, or audit. Logs and artifacts can also contain sensitive material; restrict the archive to the people who need it and follow the repository’s data-handling rules.
One open-source example, actions-attic, writes workflow-run, check-run, and commit-status metadata as JSONL in a separate Git ref. Its README explicitly says that it does not store job-log text or artifacts, and its workflow example requests contents: write to maintain that ref. That is a useful metadata-archive pattern to inspect, not a complete export or an endorsement. Review its code, permissions, backfill coverage, and the security of the destination before adopting any third-party archiver.
Keep cache and storage costs separate
Artifact and log retention is not cache retention. GitHub’s dependency-cache reference says entries that have not been accessed for more than seven days are removed by default, with separate size and eviction limits. Use caches to speed up builds, not to keep test evidence. For an individual artifact, the actions/upload-artifact documentation says you can set retention-days, up to the repository, organization, or enterprise limit. That changes the artifact’s expiry, not check history or workflow logs.
There is also a storage-cost wording difference across GitHub’s public pages. The August 27 retention announcement says artifacts and logs count toward billable Actions storage, while the current GitHub Actions billing guide says log files and long job summaries do not count toward the repository owner’s artifact-storage allowance. The detailed billing page separates artifact and package storage from cache storage; it does not provide an account-specific estimate for your repository. Check your current plan and usage before treating a retention change as a cost-saving measure. This guide does not estimate savings.
Disclosure: This guide was prepared with AI assistance. The read-only API process above was checked against GitHub’s documentation but was not executed against a live repository.
