Check GitLab’s keep-latest behavior before relying on artifact expiry

An expire_in value alone does not describe the retention of every pipeline artifact.

Source facts

GitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.

Source: GitLab — Job artifacts.

Applicability

This applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.

DSE recommendation

DSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.

Verification

Create harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.

Official reference

GitLab — Job artifacts. Reviewed October 15, 2026.