Artifact expiration policy silently deletes downstream artifacts after pipeline completion

Direct answer

Yes — when an artifact reaches its expire_in deadline, GitLab deletes it regardless of whether downstream pipelines reference it. Expiration is a property of the artifact record created by the producing job, not of its consumers. A downstream pipeline using needs:pipeline or the artifacts download API gets no exemption; once the upstream artifact is purged, the fetch fails at runtime, which is why the deletion feels silent.

Likely explanation vs. confirmed facts

Confirmed behavior (well-established across recent GitLab versions):

• expire_in on the producing job sets an expire_at timestamp on that job's artifacts. The expiry worker deletes them when that time passes.
• Retention cannot be configured per consumer. There is no setting that says "keep this longer because pipeline B downloads it." Control exists only at the producer (job-level expire_in) or via instance/group/project maximum expiration policies, which can override job settings.
• GitLab can keep artifacts from the most recent successful job per ref (the "Keep artifacts from most recent successful jobs" setting). This is a likely reason some downstream fetches keep working while older ones break — but it is version- and plan-sensitive, so treat it as the uncertain part and verify it on your instance.

What to do in your case

1. For artifacts that downstream pipelines depend on, set a longer expire_in on the producing job (or expire_in: never, accepting the storage cost and any instance-level maximum that may still apply).
2. For one-off protection, call the keep endpoint, which clears expiration for that job's artifacts:

curl --request POST --header "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.example.com/api/v4/projects/$PROJECT_ID/jobs/$JOB_ID/artifacts/keep"

Checking expiration before purge

Yes, there is an API for this. The Jobs API exposes artifact metadata including expire_at:

curl --header "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.example.com/api/v4/projects/$PROJECT_ID/jobs/$JOB_ID" \
  | jq '.artifacts[] | {filename, expire_at}'

You can poll this before triggering a downstream pipeline, or run it in a scheduled job to alert on artifacts nearing expiry.

Verifying the failure mode

To confirm this is actually your problem rather than a permissions or ref issue: set a short expire_in: 5 minutes on the producing job in a test branch, run the pipeline, wait, then trigger the downstream pipeline. If the artifact download step fails with a missing-artifact error, expiration is the cause. Also check your project and (if self-managed) admin CI/CD settings for the keep-latest-artifacts toggle and any maximum expiration override, since defaults differ between GitLab.com and self-managed instances and have changed across releases.

One missing detail

If downstream fetches fail before the expire_at timestamp shown by the API, share the exact error from the downstream job log — that would point to a different cause (ref mismatch, pipeline source, or permissions) and change the recommendation.