GitHub Actions Changes Retention for Checks and Workflow Runs

GitHub Actions generates a lot of information while a workflow runs. Logs, check results, artifacts, and workflow-run data are useful when debugging a failed deployment or investigating what happened during a release.

The problem is that keeping all of this information forever is not practical.

As repositories grow, workflow history can become large, and organizations may also have retention requirements around build artifacts and security-related information.

Changes to the retention behavior of GitHub Actions checks and workflow runs therefore matter to developers who depend on Actions for CI/CD.

A workflow that previously allowed developers to inspect older runs may behave differently once its retention period is reached. If teams do not understand the retention policy, they can lose access to information they expected to keep.

This article explains what GitHub Actions retention means, what workflow-run and check data is used for, how retention affects CI/CD operations, and how teams can design pipelines that do not depend on indefinitely available workflow history.

What Is GitHub Actions Retention?

GitHub Actions retention determines how long certain workflow-related information remains available.

A workflow can generate several types of data, including:

Workflow runs
Logs
Checks
Artifacts
Test results
Build outputs
Deployment information

Not all of these are necessarily governed by exactly the same rules.

For developers, the important concept is that workflow data has a lifecycle.

A simplified model looks like this:

Workflow starts
      |
      v
Build and tests
      |
      v
Logs and checks generated
      |
      v
Workflow completed
      |
      v
Retention period
      |
      v
Data eventually expires

This is different from source code, which normally remains in Git history until someone explicitly changes or removes it.

Why Retention Matters

Consider a production deployment that happened several months ago.

A developer receives a support request:

"Which build was deployed to production?"

The team may want to inspect the corresponding GitHub Actions run.

If that run is outside the configured retention period, the workflow information may no longer be available.

This can make troubleshooting harder.

The same problem can occur when investigating:

Deployment failures
Security incidents
Regression bugs
Build differences
Test failures
Release history
Compliance questions

Retention is therefore an operational concern, not simply a storage setting.

Workflow Runs and Checks Are Different Concepts

Developers sometimes treat workflow runs and checks as the same thing.

They are related, but they serve different purposes.

A workflow run represents an execution of a GitHub Actions workflow.

For example:

Build
  |
  +-- Checkout
  +-- Restore dependencies
  +-- Compile
  +-- Test
  +-- Package

A check provides status information associated with a commit or code change.

For example:

Commit
  |
  +-- Build: Passed
  +-- Unit Tests: Passed
  +-- Security Scan: Passed
  +-- Code Quality: Passed

Both can be useful when investigating a change.

What Happens When Workflow Data Expires?

When retained workflow information reaches its expiration point, developers may no longer be able to use it as a historical source.

For example:

Day 1
Workflow runs
   |
   v
Available

Day 30
Workflow runs
   |
   v
Available

After retention period
Workflow data
   |
   v
Expired

The exact behavior depends on the type of data and the repository or organization configuration.

This is why teams should not use GitHub Actions history as the only long-term record for information they are required to retain.

Retention and CI/CD Design

A good CI/CD pipeline should assume that workflow history is temporary.

For example, this is a fragile operational model:

GitHub Actions
      |
      v
Workflow run
      |
      v
"Keep it forever"

A better model is:

GitHub Actions
      |
      +--> Temporary logs
      |
      +--> Temporary artifacts
      |
      v
Long-term records
      |
      +--> Release metadata
      +--> Deployment system
      +--> Artifact repository
      +--> Security system

The idea is to keep each type of information in the system that is designed for it.

Configure Retention Intentionally

Teams should review their repository and organization retention settings rather than relying on defaults.

For example, GitHub Actions supports retention configuration through workflow or repository settings.

A workflow can specify retention for artifacts:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Build application
        run: dotnet build --configuration Release

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: application-build
          path: ./bin/Release
          retention-days: 14

Here, the artifact is intentionally retained for a limited period.

The correct value depends on the project's requirements.

A development project may need only a short retention period.

A production release process may require longer availability for operational reasons.

Do Not Confuse Artifact Retention With Workflow Retention

This distinction is important.

Suppose a workflow produces:

Workflow Run
   |
   +--> Logs
   |
   +--> Checks
   |
   +--> Build Artifact
   |
   +--> Test Results

Each type of information may have different retention behavior.

For example, setting:

retention-days: 14

on an uploaded artifact controls the artifact's retention.

It does not mean every piece of workflow information is retained for exactly 14 days.

Developers should therefore check the specific retention policy for the data they depend on.

Why Long-Term Build Artifacts Need Special Handling

A common mistake is using GitHub Actions artifacts as a permanent artifact repository.

For example:

Production release
       |
       v
GitHub Actions artifact
       |
       v
"Keep it forever"

This is not always the right design.

For important production releases, organizations may use a dedicated artifact repository or package registry.

The build pipeline can then publish the release artifact there.

For a .NET application, the workflow might produce:

dotnet publish \
  --configuration Release \
  --output ./publish

The resulting application can then be stored in the organization's chosen artifact system.

This separates:

CI execution data
Temporary build artifacts
Long-term release artifacts

Build IDs Should Not Be Your Only Release Record

Suppose production is running build:

Build 1847

If the corresponding workflow information expires, the number alone may not provide enough context.

A better release record should include information such as:

Application: Orders API
Version: 4.8.2
Commit: abc1234
Build: 1847
Environment: Production
Deployment time: Recorded by deployment system
Artifact: Stored in artifact repository

This creates a durable relationship between the source commit, build, artifact, and deployment.

Use Git Tags for Release Identification

Git tags are useful for marking important releases.

For example:

git tag v4.8.2
git push origin v4.8.2

The tag remains part of the repository's Git history.

That makes it a better long-term release identifier than relying only on a workflow-run record.

A production release can therefore be associated with:

Git tag
   |
   v
Commit
   |
   v
Build
   |
   v
Artifact
   |
   v
Deployment

The CI/CD system can provide the execution details while Git and the artifact repository provide durable release references.

Common Mistakes

Assuming Workflow History Is Permanent

Workflow history has retention policies.

Do not assume an old run will always be available.

Storing Important Documentation Only in Logs

Logs are useful for debugging but are not a good replacement for permanent documentation.

Treating CI Artifacts as Permanent Storage

Artifacts are often designed for temporary workflow output.

Important releases should be stored according to the organization's artifact-retention requirements.

Keeping Everything for the Maximum Period

Long retention consumes storage and can increase the amount of operational data that needs to be managed.

Retention should match actual requirements.

Not Testing Retention Policies

Teams sometimes discover retention problems only when they need an old build.

Retention should be reviewed as part of CI/CD maintenance.

How Retention Affects Troubleshooting

Imagine a deployment failed six months ago.

The developer tries to open the workflow run:

Repository
   |
   v
Actions
   |
   v
Workflow
   |
   v
Old run
   |
   v
No longer available

The team now has fewer diagnostic details.

A stronger operational process would already have preserved important information such as:

Release version
Commit SHA
Deployment status
Artifact identifier
Application version
Infrastructure version
Relevant incident ticket

This reduces dependency on old CI logs.

Security and Retention

Retention also has a security dimension.

CI logs can sometimes contain sensitive information if workflows are poorly configured.

For example:

API response
Connection string
Debug output
Environment configuration

A long retention period can increase the lifetime of accidentally exposed information.

Developers should therefore avoid printing secrets in workflow logs.

Bad:

echo "Token: $API_TOKEN"

Better:

echo "Authentication token configured"

Never log the actual credential.

Shorter retention can reduce exposure duration, but it is not a substitute for preventing secrets from appearing in logs.

Retention and Compliance

Some organizations need to retain certain records for longer periods.

This creates an important design question:

What information is actually required to be retained?

For example, a compliance process might require records of:

Production deployments
Approvals
Security scans
Release versions
Change history

The answer should not automatically be "keep every GitHub Actions log forever."

Instead, identify the required evidence and store it in an appropriate long-term system.

Best Practices

Define Retention by Data Type

Do not treat all CI/CD information equally.

Classify data such as:

Logs
Checks
Build artifacts
Test results
Release records
Deployment records

Then determine how long each type needs to remain available.

Keep Production Artifacts Separately

Important production artifacts should have a lifecycle appropriate for the business.

Use a dedicated artifact-management approach where necessary.

Record Release Metadata

At minimum, record:

Application
Version
Commit SHA
Build identifier
Artifact identifier
Deployment environment
Deployment status

Avoid Sensitive Logging

Review workflow scripts and actions for accidental secret output.

Review Retention Regularly

Retention policies should be part of CI/CD maintenance.

Revisit them when:

The application grows
Compliance requirements change
The release process changes
The number of workflows increases
Incident-response requirements change

Advantages of Controlled Retention

Lower Storage Usage

Keeping temporary workflow data for an appropriate period reduces unnecessary storage.

Better Security Hygiene

Sensitive information has less opportunity to remain in temporary logs when retention is managed appropriately.

Clearer CI/CD Operations

Teams understand which information is temporary and which information must be preserved.

Easier Compliance Planning

Required records can be intentionally stored in systems designed for long-term retention.

Disadvantages and Risks

Historical Data Can Disappear

If retention is too short, developers may lose useful debugging information.

More Infrastructure May Be Required

Long-term release records and artifacts may need dedicated systems.

Configuration Can Become Complex

Large organizations may have different retention requirements for different repositories.

Incorrect Policies Can Cause Operational Problems

Deleting data too quickly can be just as problematic as keeping everything indefinitely.

Troubleshooting Checklist

If an old workflow or artifact is no longer available, check:

What type of data are you trying to recover?
What retention policy applies to it?
Was the item explicitly configured with a shorter retention period?
Was the repository or organization policy changed?
Is the required information available in Git history?
Is the release artifact stored elsewhere?
Is there a deployment record?
Is there an incident or change-management ticket?
Can the build be reproduced from the original commit?

The final question is particularly useful.

A reproducible build process can reduce dependence on historical workflow logs.

Designing a More Reliable Release History

A mature release process should look something like this:

Source Commit
     |
     v
CI/CD Build
     |
     +--> Tests
     +--> Security Checks
     +--> Package
     |
     v
Artifact Repository
     |
     v
Deployment
     |
     v
Release Record

GitHub Actions remains responsible for executing the workflow.

The artifact repository stores important build outputs.

The deployment system records where and when the artifact was deployed.

Git stores the source history.

Each system has a clear responsibility.

Production Checklist

Before changing your GitHub Actions retention settings, verify:

Which workflow data the team actually needs.
How long logs need to remain available.
How long artifacts need to remain available.
Whether production artifacts are stored separately.
Whether deployment records are retained.
Whether release tags are created.
Whether build and deployment metadata are recorded.
Whether CI logs contain sensitive information.
Whether security investigations require historical workflow data.
Whether compliance requires longer retention.
Whether retention changes have been tested.

Summary

GitHub Actions retention is an important part of CI/CD operations because workflow runs, checks, logs, and artifacts are not necessarily permanent records.

The right approach is not to keep everything forever. Instead, teams should decide which information is temporary and which information must be preserved for operational, security, or compliance reasons.

For important production releases, use durable release identifiers such as Git tags, preserve important artifacts in an appropriate artifact repository, and maintain deployment records that connect the deployed version to its source commit.

Most importantly, do not make your incident-response process dependent on old workflow logs being available indefinitely.

A well-designed CI/CD system should make the relationship between source code, workflow execution, artifacts, and production deployments clear even after temporary workflow data has expired.

The problem is that keeping all of this information forever is not practical.

As repositories grow, workflow history can become large, and organizations may also have retention requirements around build artifacts and security-related information.

Changes to the retention behavior of GitHub Actions checks and workflow runs therefore matter to developers who depend on Actions for CI/CD.

What Is GitHub Actions Retention?

GitHub Actions retention determines how long certain workflow-related information remains available.

A workflow can generate several types of data, including:

Workflow runs
Logs
Checks
Artifacts
Test results
Build outputs
Deployment information

Not all of these are necessarily governed by exactly the same rules.

For developers, the important concept is that workflow data has a lifecycle.

A simplified model looks like this:

Workflow starts
      |
      v
Build and tests
      |
      v
Logs and checks generated
      |
      v
Workflow completed
      |
      v
Retention period
      |
      v
Data eventually expires

This is different from source code, which normally remains in Git history until someone explicitly changes or removes it.

Why Retention Matters

Consider a production deployment that happened several months ago.

A developer receives a support request:

"Which build was deployed to production?"

The team may want to inspect the corresponding GitHub Actions run.

If that run is outside the configured retention period, the workflow information may no longer be available.

This can make troubleshooting harder.

The same problem can occur when investigating:

Deployment failures
Security incidents
Regression bugs
Build differences
Test failures
Release history
Compliance questions

Retention is therefore an operational concern, not simply a storage setting.

Workflow Runs and Checks Are Different Concepts

Developers sometimes treat workflow runs and checks as the same thing.

They are related, but they serve different purposes.

A workflow run represents an execution of a GitHub Actions workflow.

For example:

Build
  |
  +-- Checkout
  +-- Restore dependencies
  +-- Compile
  +-- Test
  +-- Package

A check provides status information associated with a commit or code change.

For example:

Commit
  |
  +-- Build: Passed
  +-- Unit Tests: Passed
  +-- Security Scan: Passed
  +-- Code Quality: Passed

Both can be useful when investigating a change.

What Happens When Workflow Data Expires?

When retained workflow information reaches its expiration point, developers may no longer be able to use it as a historical source.

For example:

Day 1
Workflow runs
   |
   v
Available

Day 30
Workflow runs
   |
   v
Available

After retention period
Workflow data
   |
   v
Expired

The exact behavior depends on the type of data and the repository or organization configuration.

This is why teams should not use GitHub Actions history as the only long-term record for information they are required to retain.

Retention and CI/CD Design

A good CI/CD pipeline should assume that workflow history is temporary.

For example, this is a fragile operational model:

GitHub Actions
      |
      v
Workflow run
      |
      v
"Keep it forever"

A better model is:

GitHub Actions
      |
      +--> Temporary logs
      |
      +--> Temporary artifacts
      |
      v
Long-term records
      |
      +--> Release metadata
      +--> Deployment system
      +--> Artifact repository
      +--> Security system

The idea is to keep each type of information in the system that is designed for it.

Configure Retention Intentionally

Teams should review their repository and organization retention settings rather than relying on defaults.

For example, GitHub Actions supports retention configuration through workflow or repository settings.

A workflow can specify retention for artifacts:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Build application
        run: dotnet build --configuration Release

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: application-build
          path: ./bin/Release
          retention-days: 14

Here, the artifact is intentionally retained for a limited period.

The correct value depends on the project's requirements.

A development project may need only a short retention period.

A production release process may require longer availability for operational reasons.

Do Not Confuse Artifact Retention With Workflow Retention

This distinction is important.

Suppose a workflow produces:

Workflow Run
   |
   +--> Logs
   |
   +--> Checks
   |
   +--> Build Artifact
   |
   +--> Test Results

Each type of information may have different retention behavior.

For example, setting:

retention-days: 14

on an uploaded artifact controls the artifact's retention.

It does not mean every piece of workflow information is retained for exactly 14 days.

Developers should therefore check the specific retention policy for the data they depend on.

Why Long-Term Build Artifacts Need Special Handling

A common mistake is using GitHub Actions artifacts as a permanent artifact repository.

For example:

Production release
       |
       v
GitHub Actions artifact
       |
       v
"Keep it forever"

This is not always the right design.

For important production releases, organizations may use a dedicated artifact repository or package registry.

The build pipeline can then publish the release artifact there.

For a .NET application, the workflow might produce:

dotnet publish \
  --configuration Release \
  --output ./publish

The resulting application can then be stored in the organization's chosen artifact system.

This separates:

CI execution data
Temporary build artifacts
Long-term release artifacts

Build IDs Should Not Be Your Only Release Record

Suppose production is running build:

Build 1847

If the corresponding workflow information expires, the number alone may not provide enough context.

A better release record should include information such as:

Application: Orders API
Version: 4.8.2
Commit: abc1234
Build: 1847
Environment: Production
Deployment time: Recorded by deployment system
Artifact: Stored in artifact repository

This creates a durable relationship between the source commit, build, artifact, and deployment.

Use Git Tags for Release Identification

Git tags are useful for marking important releases.

For example:

git tag v4.8.2
git push origin v4.8.2

The tag remains part of the repository's Git history.

That makes it a better long-term release identifier than relying only on a workflow-run record.

A production release can therefore be associated with:

Git tag
   |
   v
Commit
   |
   v
Build
   |
   v
Artifact
   |
   v
Deployment

The CI/CD system can provide the execution details while Git and the artifact repository provide durable release references.

Common Mistakes

Assuming Workflow History Is Permanent

Workflow history has retention policies.

Do not assume an old run will always be available.

Storing Important Documentation Only in Logs

Logs are useful for debugging but are not a good replacement for permanent documentation.

Treating CI Artifacts as Permanent Storage

Artifacts are often designed for temporary workflow output.

Important releases should be stored according to the organization's artifact-retention requirements.

Keeping Everything for the Maximum Period

Long retention consumes storage and can increase the amount of operational data that needs to be managed.

Retention should match actual requirements.

Not Testing Retention Policies

Teams sometimes discover retention problems only when they need an old build.

Retention should be reviewed as part of CI/CD maintenance.

How Retention Affects Troubleshooting

Imagine a deployment failed six months ago.

The developer tries to open the workflow run:

Repository
   |
   v
Actions
   |
   v
Workflow
   |
   v
Old run
   |
   v
No longer available

The team now has fewer diagnostic details.

A stronger operational process would already have preserved important information such as:

Release version
Commit SHA
Deployment status
Artifact identifier
Application version
Infrastructure version
Relevant incident ticket

This reduces dependency on old CI logs.

Security and Retention

Retention also has a security dimension.

CI logs can sometimes contain sensitive information if workflows are poorly configured.

For example:

API response
Connection string
Debug output
Environment configuration

A long retention period can increase the lifetime of accidentally exposed information.

Developers should therefore avoid printing secrets in workflow logs.

Bad:

echo "Token: $API_TOKEN"

Better:

echo "Authentication token configured"

Never log the actual credential.

Shorter retention can reduce exposure duration, but it is not a substitute for preventing secrets from appearing in logs.

Retention and Compliance

Some organizations need to retain certain records for longer periods.

This creates an important design question:

What information is actually required to be retained?

For example, a compliance process might require records of:

Production deployments
Approvals
Security scans
Release versions
Change history

The answer should not automatically be "keep every GitHub Actions log forever."

Instead, identify the required evidence and store it in an appropriate long-term system.

Best Practices

Define Retention by Data Type

Do not treat all CI/CD information equally.

Classify data such as:

Logs
Checks
Build artifacts
Test results
Release records
Deployment records

Then determine how long each type needs to remain available.

Keep Production Artifacts Separately

Important production artifacts should have a lifecycle appropriate for the business.

Use a dedicated artifact-management approach where necessary.

Record Release Metadata

At minimum, record:

Application
Version
Commit SHA
Build identifier
Artifact identifier
Deployment environment
Deployment status

Avoid Sensitive Logging

Review workflow scripts and actions for accidental secret output.

Review Retention Regularly

Retention policies should be part of CI/CD maintenance.

Revisit them when:

The application grows
Compliance requirements change
The release process changes
The number of workflows increases
Incident-response requirements change

Advantages of Controlled Retention

Lower Storage Usage

Keeping temporary workflow data for an appropriate period reduces unnecessary storage.

Better Security Hygiene

Sensitive information has less opportunity to remain in temporary logs when retention is managed appropriately.

Clearer CI/CD Operations

Teams understand which information is temporary and which information must be preserved.

Easier Compliance Planning

Required records can be intentionally stored in systems designed for long-term retention.

Disadvantages and Risks

Historical Data Can Disappear

If retention is too short, developers may lose useful debugging information.

More Infrastructure May Be Required

Long-term release records and artifacts may need dedicated systems.

Configuration Can Become Complex

Large organizations may have different retention requirements for different repositories.

Incorrect Policies Can Cause Operational Problems

Deleting data too quickly can be just as problematic as keeping everything indefinitely.

Troubleshooting Checklist

If an old workflow or artifact is no longer available, check:

What type of data are you trying to recover?
What retention policy applies to it?
Was the item explicitly configured with a shorter retention period?
Was the repository or organization policy changed?
Is the required information available in Git history?
Is the release artifact stored elsewhere?
Is there a deployment record?
Is there an incident or change-management ticket?
Can the build be reproduced from the original commit?

The final question is particularly useful.

A reproducible build process can reduce dependence on historical workflow logs.

Designing a More Reliable Release History

A mature release process should look something like this:

Source Commit
     |
     v
CI/CD Build
     |
     +--> Tests
     +--> Security Checks
     +--> Package
     |
     v
Artifact Repository
     |
     v
Deployment
     |
     v
Release Record

GitHub Actions remains responsible for executing the workflow.

The artifact repository stores important build outputs.

The deployment system records where and when the artifact was deployed.

Git stores the source history.

Each system has a clear responsibility.

Production Checklist

Before changing your GitHub Actions retention settings, verify:

Which workflow data the team actually needs.
How long logs need to remain available.
How long artifacts need to remain available.
Whether production artifacts are stored separately.
Whether deployment records are retained.
Whether release tags are created.
Whether build and deployment metadata are recorded.
Whether CI logs contain sensitive information.
Whether security investigations require historical workflow data.
Whether compliance requires longer retention.
Whether retention changes have been tested.

Summary

GitHub Actions retention is an important part of CI/CD operations because workflow runs, checks, logs, and artifacts are not necessarily permanent records.

Most importantly, do not make your incident-response process dependent on old workflow logs being available indefinitely.

A well-designed CI/CD system should make the relationship between source code, workflow execution, artifacts, and production deployments clear even after temporary workflow data has expired.