What to know

  • Retention now covers checks, workflow runs and statuses.
  • Third-party application checks and statuses are included.
  • Increasing retention does not recover previously removed records.

More records share the same clock

GitHub said on October 1 that checks, workflow runs and statuses now follow the Actions retention setting previously used for artifacts and logs. The policy includes checks and statuses from third-party applications. Repository settings remain subject to organization and enterprise caps, and public repositories have a 90-day maximum. A later increase to the setting cannot restore records already removed.

This is a change in how long evidence stays available, rather than a new test of code quality. A successful release may depend on a chain of checks that people need to consult months later. If those records expire under a setting chosen for routine logs, the team may discover the gap only when investigating a defect or reconstructing why a change was approved.

Source: GitHub: Expanded Actions retention

Analysis: Operational history and release evidence differ

Not every test run needs permanent storage. Temporary branches and repeated experiments can produce considerable noise. A release decision, however, may depend on a smaller set of facts: the exact revision, the checks performed, their results, and the person or policy that approved deployment. Defining that record separately can make retention more deliberate.

A hypothetical audit illustrates the distinction. A team may still possess the shipped binary but lack the result of a check that was required when it was built. Rebuilding later can answer a new question about the code under today’s environment. It cannot automatically recreate the historical decision, particularly if dependencies, test inputs or external services changed. That makes a retained release record useful even when rerunning tests is possible.

Practical implications: Inspect the evidence you rely on

Engineering owners can review the renamed retention setting and identify which reports they currently retrieve from Actions during incidents or compliance work. They should map the required lifetime of those records to the actual platform limits. Where a separate archive is needed, it should retain only the relevant evidence with appropriate access controls and a clear relationship to the release.

The practical check is straightforward: select an older release and try to reconstruct its approval path using existing records. Missing information reveals a workflow issue before an urgent investigation does. GitHub’s update supplies a consistent cleanup rule, but it does not choose an organization’s evidence requirements. Teams need that decision to be explicit, owned and tested against the records they expect to find when a past deployment comes under scrutiny.

Evidence ownership should survive staff changes. If the only person who knows where a release report was saved leaves the team, an archive may exist without being usable. Documenting retrieval is therefore part of the retention decision.

Sources & further reading

  1. GitHub: Expanded Actions retention

Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.

Microsoft

The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.

Corrections policy · About this byline