# What Is Artifact Retention? — Default Windows and the Four Ways Links Die

Canonical: https://commareports.com/glossary/artifact-retention
Published: 2026-09-11

> Artifact retention is the policy deciding how long CI keeps a build output before deleting it. Default windows per provider, the three non-retention deleters, and why re-running is not recovery.

# Artifact retention

**Artifact retention is the policy that decides how long a CI system
stores a [build artifact](/glossary/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](/docs/ci)).

## Try it

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

**[Create a link that doesn't expire →](https://commareports.com/)**

### Related

- [The CI artifact link expired](/fix/ci-artifact-expired) — the full recovery walkthrough
- [Build artifact](/glossary/build-artifact) · [Static site hosting](/glossary/static-site-hosting)
- [GitLab CI HTML reports](/ci/gitlab-ci-html-report) · [Glossary](/glossary)