GitLab CI artifacts expiring too fast: retention config

TL;DR

GitLab artifacts expire on two clocks: the job-level expirein and the instance-level max, and the shorter one wins. Set expirein per job for what that job's artifacts actually need, use longer retention only for release jobs, and remember that artifacts kept forever are storage quota burned forever. Most teams need hours for test reports and months only for release binaries.

The query

GitLab CI artifacts expiring too fast: retention config

Use this when

• Artifacts disappear before anyone downloads them
• Release artifacts need to outlive the default 30 days
• Storage quotas are filling with old artifacts
• Different jobs need different retention

Not for when

• CI cache configuration (caches are separate from artifacts)
• Storing artifacts outside GitLab (object storage, registries)
• Pipeline scheduling or triggering

Steps

Step 1: Find which clock is expiring your artifacts

Check the job's expire_in setting and the instance's max artifact lifetime. If the job sets 1 day and the instance allows 30, the job wins. If the job sets nothing, the instance default applies. Know both numbers. Expected output: the effective expiry for the job's artifacts, and which setting controls it.

Step 2: Set expire_in per job by artifact purpose

Test reports and coverage: hours to a few days. Build outputs consumed by later jobs: 1 day. Release binaries: months or never for tagged releases. One global value is always wrong for someone. Expected output: each job's expire_in matches how long its artifacts are actually useful.

Step 3: Keep release artifacts explicitly

For jobs that produce releases, set a long expire_in or never, and consider also pushing the artifact to a release asset or package registry. CI artifacts are not an archive; the registry is. Expected output: release artifacts survive indefinitely in the right system, not just in CI.

Step 4: Clean up what you no longer need

Periodically review artifact storage per project. Old branches' artifacts are the usual quota hog. GitLab expires them automatically per the settings, but never-expire artifacts accumulate; audit them. Expected output: storage usage stable; no surprise quota exhaustion.

Step 5: Document the retention policy

Write down the per-job-type retention so the next person does not set everything to never-expire out of caution. Link it from the CI docs. Expected output: a short retention table everyone follows instead of guessing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__jJI6HTW8kfakPCpWeCqZQ