What is artifact retention?

Artifact retention is the policy that decides how long a CI system stores a build output before permanently deleting it. It is set per provider, often per repository or per job, and it applies to every artifact link that has ever been pasted into a pull request or an incident document.

What are the default artifact retention windows?

GitHub Actions keeps artifacts 90 days by default (configurable 1–90 days at the repository level, up to 400 for some org settings). GitLab defaults to 30 days per job unless `expire_in` overrides it. CircleCI keeps 30 days. Jenkins keeps whatever the job's build discarder says, which is frequently a build count rather than an age.

Can you recover an expired artifact?

Not from the provider. Retention deletion is permanent, there is no undelete on any major CI system, and support cannot restore it. The only option is re-running the job, which produces a different document with a new date on it.

Why do artifact links break before the retention window is up?

Retention is only one of four deleters. GitLab's keep-latest-successful setting removes superseded pipelines' artifacts at any age, Jenkins discarders delete by build count, and making a repository private revokes anonymous access to links that previously worked.

Artifact retention

Artifact retention is the policy that decides how long a CI system stores a build artifact before permanently deleting it. It applies to every artifact link ever pasted into a pull request, a ticket or an incident write-up.

Default windows

Provider	Default	Configurable
GitHub Actions	90 days	1–90 per repo; up to 400 at org level
GitLab CI	30 days	Per job via `expire_in`
CircleCI	30 days	Per project
Azure Pipelines	30 days	Per pipeline retention rules
Bitbucket Pipelines	14 days	Fixed on most plans
Jenkins	Per job	Build discarder — often by count

The defaults are all shorter than the life of a document. A compliance scan cited in an audit, a benchmark you claimed a regression against, the coverage report attached to a design decision — all of them outlive 90 days routinely.

Retention is not the only deleter

Three other mechanisms remove artifacts inside the window, and they are the ones that actually surprise people:

Keep-latest-successful (GitLab). Superseded pipelines lose their artifacts immediately, at any age. A busy branch can retire yesterday's report today.
Count-based discarders (Jenkins, TeamCity). "Keep last 10 builds" means ten green builds erase build #1 — possibly within an hour.
Visibility changes. A repository going private revokes anonymous access to every link that used to work, retention untouched.

Re-running is not recovery

Deletion is permanent everywhere. The only remaining option is running the job again, which is often a mirage:

The commit resolves, but the runner image has moved on.
A fresh install pulls different transitive dependency versions.
A scanner's vulnerability database has been updated, so the report you regenerate is a different report.
The external service the test hit has changed its responses.

For anything citable, a regenerated report is new evidence with a new date — not the document that was referenced.

The split that fixes it

Retention is correct for machine artifacts and wrong for documents. Keep uploading caches, binaries and result XML under a short window. Publish the human-readable report to an address you own, PATCHed on every run against a single id, so the URL is stable for the life of the project and each run is appended as a revision rather than replacing the last one (publish from CI).

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history. Nothing expires.

Create a link that doesn't expire →

The CI artifact link expired — the full recovery walkthrough
Build artifact · Static site hosting
GitLab CI HTML reports · Glossary