GitHub Pipelines Log Retention: The Default, the Override, and the Audit Trail That Survives a Year

GitHub Actions keeps workflow logs for 90 days for private repos and indefinitely for public repos. The retention can be set per-workflow (1-90 days) and overridden org-wide (1-90 days for all private repos). The storage cost is free for the default 90 days and billed per GB-month above a free quota for shorter retentions. The reason “github pipelines log retention” is still a top search is that the default is invisible until a log disappears three months after a deploy, and the audit trail for compliance is rarely a 90-day story.

This post is the part of the docs that explains what the retention actually does, the trade-off between short retention (cheaper, less audit) and long retention (more expensive, more audit), and the right pattern for a team that needs both.

Table of contents

• The direct answer: 90 days, with three overrides
• The override at the workflow level
• The override at the org and enterprise level
• The cost story: free at 90 days, billed below
• The audit trail problem and the right shape
• The pattern: short retention, external archive
• The artifact-vs-log distinction
• FAQ

The direct answer: 90 days, with three overrides

For a private repo, the default workflow log retention is 90 days. After 90 days, the log is deleted from GitHub’s storage, and the workflow run shows as a “deleted” entry in the Actions tab. The workflow metadata (the run ID, the commit, the conclusion) is preserved, but the log content is gone.

For a public repo, the default is indefinite. The log is kept as long as the repo exists, which is forever for a public repo.

The three places to override the default:

1. Per workflow, in the workflow YAML, with the retention-days field on the actions/upload-artifact step (for artifacts) or with no direct equivalent for logs (logs follow the repo or org default).
2. Per repo, in Settings > Actions > General > Artifact and log retention. The dropdown offers 1, 3, 7, 14, 30, 60, and 90 days.
3. Per org or enterprise, in the same Settings path, with a default that applies to every repo. The org-level default is the strongest.

The retention is for both logs and artifacts, but with an important caveat: the retention-days field on actions/upload-artifact overrides only the artifact, not the log. To shorten the log retention, use the repo or org setting.

The override at the workflow level

The per-workflow override is for artifacts, not logs. The pattern:

- name: Upload build artifact
  uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/
    retention-days: 7

The retention-days field accepts a value from 1 to 90 (inclusive, as of writing). The artifact is deleted after the specified number of days, regardless of the repo or org default.

For logs, the equivalent override does not exist at the workflow level. The log follows the repo or org default. The workaround for a workflow that produces logs you want to keep longer than the default is to ship the logs to an external destination (S3, CloudWatch, a log aggregator) inside the workflow, which is the right pattern for a compliance-driven audit trail anyway.

The override at the org and enterprise level

For an organization, the default is set in Settings > Actions > General > Artifact and log retention. The dropdown offers the same 1-90 day range, and the setting applies to every private repo in the org that does not override it. A public repo is unaffected (the public default is indefinite).

For an enterprise, the same setting exists in the enterprise admin panel, and it overrides the org default. The enterprise setting is the right place for a compliance-driven policy that needs to apply across the company.

The override cascade:

1. Enterprise default (if set)
2. Org default (if set)
3. Repo default (if set)
4. Workflow artifact retention-days (for artifacts only)

The lowest-numbered override wins, which is the right shape: a strict enterprise compliance policy can enforce a 30-day retention, and a repo can choose a longer retention if it has a justified business need.

The cost story: free at 90 days, billed below

GitHub’s storage is free for the default 90-day retention. Storage with shorter retention (1-89 days) is also free up to a quota, and then billed per GB-month above the quota. The exact numbers shift with each pricing change, but the shape is the same: short retention is cheaper, and the free tier covers most teams.

The interesting cost is not the storage. The interesting cost is the time spent in month three when an engineer needs a log from a deploy that ran 100 days ago and the log is gone. The cost of “we don’t have that log anymore” is a real cost — incident response time, audit failure, the inability to investigate a regression.

The right sizing is not “the cheapest.” The right sizing is “the retention that supports the longest expected gap between ‘we ran this’ and ‘we needed to look at it again.’” For most teams, that is 90 days. For compliance-driven teams (SOC 2, ISO 27001, HIPAA), that is one year or longer.

The audit trail problem and the right shape

GitHub’s log retention is for log content, not for the audit trail of who ran what when. The audit trail of workflow runs (the metadata: who triggered, when, what the conclusion was, what commit it ran against) is preserved indefinitely, even after the log is deleted. The audit trail of the actions taken in the workflow (the steps, the inputs, the outputs) is part of the log, which is subject to the retention.

For a compliance audit, the right shape is:

1. Keep the GitHub log at the default 90 days for fast investigation.
2. Ship the same logs to an external store (S3, CloudWatch, a SIEM) for long-term retention.
3. Use the GitHub audit log API to capture who triggered what workflow when, with a separate retention policy (usually one year or longer).

The shipping is the part most teams skip. The pattern:

- name: Archive workflow logs
  if: always()
  run: |
    # Ship the entire log to S3
    aws s3 cp $GITHUB_STEP_SUMMARY /tmp/log.txt || true
    aws s3 cp /tmp/log.txt s3://my-logs-bucket/$GITHUB_REPOSITORY/$GITHUB_RUN_ID/log.txt

The if: always() ensures the archive runs even when the workflow fails. The destination is a per-repo prefix, so logs are easy to find. The retention on the S3 bucket is set by the bucket’s lifecycle policy, which is independent of GitHub’s.

For a real production setup, the right tool is a dedicated log aggregator (Datadog, New Relic, a self-hosted Loki) that ingests workflow logs as part of the platform’s normal log pipeline. The S3 archive is the cold storage, the aggregator is the warm storage, and GitHub is the hot storage for the most recent 90 days.

The pattern: short retention, external archive

For a team that has outgrown GitHub’s log retention:

1. Set the repo retention to 30 days in Settings > Actions > General. This is short enough to keep the storage cost low and long enough to investigate most issues.
2. Ship the logs to S3 (or equivalent) in every workflow that produces logs you might need to investigate. The if: always() step above is the right pattern.
3. Set the S3 lifecycle policy to transition logs to Glacier after 90 days and delete after 365 days (or whatever the compliance policy requires).
4. Set the GitHub audit log retention to one year in the org settings. The audit log is the who/what/when, not the log content, and it is the part an auditor actually needs.
5. Document the retention policy in the team’s runbook. The pattern is “GitHub has 30 days, S3 has 365 days, audit log has one year, and here’s the script to look up a log from a given run ID.”

The pattern is more work than “set the default to 90 days and forget it.” The pattern is also the difference between “we have the logs we need” and “we have to ask the user to run the workflow again because the log is gone.”

The artifact-vs-log distinction

GitHub Actions has two kinds of retained output: logs and artifacts. The distinction matters because they have different defaults, different overrides, and different costs.

Logs — the text output of each step, the run summary, the step timings, the matrix matrix entries. The default retention is 90 days for private repos, indefinite for public. The override is per-repo or per-org, not per-workflow.

Artifacts — uploaded files (build outputs, test reports, binaries, coverage reports). The default retention matches the repo or org default, with a per-workflow override via retention-days on actions/upload-artifact. The minimum is 1 day, the maximum is 90 days (as of writing).

A useful pattern: use the per-workflow retention-days to keep large artifacts (build binaries, coverage reports) for 7-14 days, and let the repo default (30-90 days) cover the logs. The artifacts you do not need after two weeks are usually safe to delete; the logs you might need for an investigation in month three are the ones to keep.

For artifacts that need long-term retention (release binaries, signed builds), the pattern is the same as logs: ship them to S3 or a release artifact store, and let GitHub’s retention handle the short-term cache. The release artifact store is the source of truth; GitHub is the warm cache.

For a hosted CI/CD that handles log retention automatically, the same logic applies with the platform’s storage as the default. Render, for example, keeps build logs for 30 days on the free tier and longer on the paid tier; the audit trail is the platform’s responsibility. The same pattern of “ship to external store for long-term” applies when the compliance window is longer than the platform’s default. For a team that does not want to own the shipping at all, the RunxBuild deploy path keeps build logs as long as the project is active, with export to S3 as a one-click config.

How this fits the rest of the stack

Long log retention is also a storage question — the audit trail can grow to gigabytes per project per year, and the storage cost is the line item the team forgets to model until the bill arrives. The RunxBuild hosting calculator is the right place to model that — pick the log volume, the retention period, the build minutes, the bandwidth, and the storage tier, and the calculator shows what the audit trail actually costs at the team’s actual usage.

Useful related references:

• build pipeline
• logs dashboard
• environment variables

FAQ

How long does GitHub keep workflow logs?

90 days for private repos by default, indefinitely for public repos. The retention is per-repo and per-org, with overrides in Settings > Actions > General > Artifact and log retention.

Can I set a custom log retention per workflow?

No. The log retention is per-repo and per-org. The per-workflow override exists for artifacts (retention-days on actions/upload-artifact) but not for logs. For longer log retention, ship the logs to an external store inside the workflow.

How do I keep logs longer than 90 days for compliance?

Set the repo or org retention to 90 days (the maximum) and ship the logs to S3, CloudWatch, or a SIEM inside the workflow. The external store has its own retention policy, which is independent of GitHub’s.

What is the difference between an artifact and a log?

Logs are the text output of each step (stdout, stderr, the step summary). Artifacts are uploaded files (build outputs, binaries, test reports). Artifacts have a per-workflow retention override; logs do not.

Does the GitHub audit log have a separate retention?

Yes. The audit log (the record of who did what in the org) is retained for 180 days in the UI, with the option to stream to an external SIEM for longer retention via the audit log API.

Can I set retention shorter than 1 day?

No. The minimum is 1 day for both logs and artifacts. The maximum for both is 90 days (as of writing). For longer retention, use an external store.