If your deployment history lives entirely in GitHub Actions, October's retention change deserves a look. The record you expect to find during a future investigation may have a shorter life than it used to.

From 1 October 2026, GitHub's Actions retention setting also governs checks, workflow runs and statuses. It already controlled artifacts and logs.

One setting now covers more records

GitHub says records exceeding the configured retention period are automatically cleaned up. The change includes checks and statuses created by third-party applications.

Repository settings remain subject to organisation and enterprise limits. Public repositories have a maximum retention of 90 days. Raising a setting does not bring back records that have already been removed.

That last point makes this worth reviewing before someone needs evidence from an older release. A deleted record is harder to explain when your process assumed it would always be there.

Work out what the team needs to retain

Different records answer different questions. A build log may explain a compiler failure. A deployment approval can explain who authorised a release. A commit identifier shows which code version shipped.

List the questions your team usually asks during a rollback, customer investigation or review. Then identify where each answer is stored and how long it remains available.

For example, a hosting team investigating a problem three months after a release might need the deployed commit, environment, deployment time and change reference. Those details can fit in a small durable record, even when the full build output is no longer needed.

Keep a release record outside the run

A practical approach is to write essential deployment information into the system your team uses for operations or change tracking. Include the application, environment, commit, time, actor and outcome.

Store only what you need. Copying every job log into another system creates its own cost and access problem, particularly if logs contain personal information or credentials.

Make the record part of the deployment process so it is created consistently. A manual task that everyone intends to do after a busy release is easy to forget.

Check applications that read old statuses

A dashboard or report may query historic checks through the API. Review how it behaves when a record has expired. It should distinguish missing history from a failed or never-run check.

  • Review repository, organisation and enterprise retention settings.
  • Identify reports and integrations that read older runs or statuses.
  • Preserve essential deployment facts in an appropriate system.
  • Test what your investigation process can retrieve after expiry.

This change gives teams a reason to be explicit about retention. Choose the records you need and the place they belong, then make sure the process can still answer a simple question: what was running when the problem happened?

Reporting checked on 13 October 2026.