Actions retention: preserve release evidence before checks and statuses expire

The release record now has a retention limit too

On October 1, 2026, GitHub announced that checks, workflow runs and statuses are now governed by the same Actions retention setting as artifacts and logs. Those records are automatically cleaned up when they exceed the configured period. The announcement explicitly includes checks and statuses created by third-party applications and applies to Actions on github.com. [1]

GitHub's August announcement described the earlier behavior as retaining checks, workflow runs and statuses for more than 400 days regardless of the configured policy. That is historical context, not a current availability promise. The change concerns how long the evidence remains available, not which workflow is authorized to release. [2]

For a team using coding agents or release automation, the practical question is whether someone can later reconstruct why a particular commit was accepted. A release tag and a link to a successful run are useful identifiers, but a link alone cannot supply a check result or decisive log once its target has been removed. This is the reason to preserve a small decision record rather than assume the GitHub page will remain readable.

What is covered—and what the setting does not prove

There is a wording mismatch worth keeping visible. At retrieval, Docs still said “Starting October 1, 2026” and “Until then,” while the October 1 announcement said the change applies “now.” We use the dated announcement for the activation statement and Docs for the configuration rules; stale future tense is not evidence of a failed rollout. These passages do not establish the exact cleanup instant, the age clock used for every record, or the migration treatment of every pre-October object. Do not turn a day count into a guaranteed deletion appointment. [1][3]

First establish the policy that actually applies

Use this proposed decision procedure before choosing a preservation schedule. Its settings path and policy limits come from GitHub; the recording and escalation steps are our operational recommendation, not actions performed for this briefing. [1][3]

• Identify the repository, its visibility and its GitHub environment. This announcement establishes github.com scope; for GitHub Enterprise Server, confirm the documentation for your server version rather than borrowing the cloud announcement. [1]
• Open repository Settings → Actions → General and locate “Check, workflow run, status, artifact and log retention.” Record the displayed value, the repository and the time you observed it. If you cannot access Settings, ask the repository administrator to confirm the value; do not substitute the documented default. [1][3]
• Confirm any managing organization or enterprise cap with the relevant administrator. Record which policy governs the repository and distinguish an allowed maximum from the configured value. If that cannot be established, treat the effective period as unconfirmed and preserve needed, currently accessible evidence promptly. [3]
• Separate new releases from older records. Note when the setting was last changed, if known, and any artifact-specific retention relevant to the evidence you need. Current settings alone do not establish the lifetime of an existing run: Docs say customization is new-object-only. [3]
• Decide how long the release must remain explainable for your team's actual support, review or contractual needs. If that horizon exceeds the confirmed availability window—or an old record's window is uncertain—plan separate preservation. Even within the window, use a safety margin, not the last presumed day.

Preserve enough to explain the release—not every byte

Our proposed minimum is a record that answers: what was released, which evidence justified it, and where that evidence can still be read. Keep original GitHub URLs as provenance alongside copied material. Select what explains the decision; this is not a recommendation to indiscriminately export every log or create a guaranteed archive.

• Bind the decision to the repository, full commit SHA, release or tag, workflow identity, run ID and attempt number. Record which attempt supplied the accepted evidence so a later rerun cannot be mistaken for it.
• Copy the relevant check or status names, provider, outcomes and timestamps. Include a short explanation of which results supported acceptance, any exception and who owned the decision. Keep selected decisive log passages or artifacts needed to substantiate that explanation.
• Record the observed retention value, managing scope and observation time, with any unresolved old-object or artifact-specific limits. Add the evidence capture time and a content digest, such as SHA-256, for each retained file. A digest helps compare copies; by itself it does not prove the release was trustworthy.
• Specify the retained location, access rules, responsible custodian and intended retention horizon. Review the selected content for secrets and unnecessary personal data before copying it, using an appropriate controlled location. A longer GitHub setting may keep associated artifacts and logs in billable storage longer; the August notice distinguishes that storage from unbilled check, run and status metadata. [2]
• Choose a capture target comfortably before possible expiry; capturing the record at release acceptance avoids relying on a later cleanup prediction. Reopen the retained files with the intended reader's access and check that the commit, outcomes and supporting content can be reconstructed without the original run page. Schedule a later readback appropriate to your retention horizon.

If a needed record has already disappeared, mark the missing evidence explicitly. Separately retained provider records or release artifacts may help if they can be tied to the exact release, but do not describe them as recovery of the deleted GitHub object. Changing the retention setting will not restore it. Nor does a surviving “success” label alone reconstruct every reason for the decision. [1]

Hypothetical completed example: a short-policy release

Everything in this example—including the repository, dates, policy, identifiers and reported checks—is fictional. It illustrates a completed decision record, not an incident or an export experiment performed by Palanthos.

The decision is not to increase the repository setting and assume an existing run is protected. It is to retain a small, readable record because the team's required explanation horizon is longer than its confirmed policy. No exact GitHub deletion time, immutable storage property or compliance outcome is inferred.

The next useful action

Choose one important recent release. Confirm its policy with the responsible administrator, identify which still-accessible check, status, run, log and artifact content explains acceptance, and preserve only the necessary material with clear custody. If policy or old-object behavior remains uncertain, capture needed evidence now rather than waiting for a presumed grace period. The procedure succeeds when an intended reader can reconstruct the decision from the retained content—not when a folder merely contains links.