Skip to content
LatchkeyLatchkey home

What Is Artifact Retention? Storing CI Outputs Sensibly

Artifact retention is the policy for how long CI holds onto the files a build produces - binaries, test reports, logs - before automatically deleting them to control storage cost.

Every run can emit artifacts: compiled binaries, coverage and test reports, screenshots, logs. Retention is the rule that decides how long those stick around. Set it too short and you lose debugging evidence; too long and storage bills balloon.

What an artifact is

An artifact is any file a job uploads to be kept after the runner is destroyed. Because runners are ephemeral, anything you want to inspect later - a failing test’s screenshot, a built package, a log bundle - must be explicitly uploaded as an artifact or it vanishes with the runner.

Why retention exists

Artifacts consume billed storage that accumulates across thousands of runs. Retention automatically deletes them after a set period so storage does not grow without bound. Providers apply a default window (often a few weeks to 90 days) that you can shorten or lengthen per artifact.

Choosing a policy

  • Short retention for large, reproducible build outputs you can rebuild.
  • Longer retention for test reports and logs you may need to debug regressions.
  • Separate per-artifact windows rather than one blanket setting.
  • Release artifacts often belong in a real registry, not CI artifact storage.

Common mistakes

Uploading huge artifacts on every run with the default long retention is the usual cause of surprise storage bills. The opposite mistake - too-short retention - deletes the evidence you needed to debug an intermittent failure. Match the window to how reproducible and how diagnostically valuable each artifact is.

Key takeaways

  • Retention sets how long CI keeps uploaded artifacts before deleting them.
  • Ephemeral runners mean anything you want later must be uploaded as an artifact.
  • Tune per-artifact windows: short for rebuildable outputs, longer for debug evidence.
  • Long retention on large per-run artifacts is a top cause of storage bill surprises.

Frequently asked questions

What is What is artifact Retention? storing CI outputs sensibly?
Every run can emit artifacts: compiled binaries, coverage and test reports, screenshots, logs. Retention is the rule that decides how long those stick around. Set it too short and you lose debugging evidence; too long and storage bills balloon.
What an artifact is?
An artifact is any file a job uploads to be kept after the runner is destroyed. Because runners are ephemeral, anything you want to inspect later - a failing test’s screenshot, a built package, a log bundle - must be explicitly uploaded as an artifact or it vanishes with the runner.
Why retention exists?
Artifacts consume billed storage that accumulates across thousands of runs. Retention automatically deletes them after a set period so storage does not grow without bound. Providers apply a default window (often a few weeks to 90 days) that you can shorten or lengthen per artifact.
Common mistakes?
Uploading huge artifacts on every run with the default long retention is the usual cause of surprise storage bills. The opposite mistake - too-short retention - deletes the evidence you needed to debug an intermittent failure. Match the window to how reproducible and how diagnostically valuable each artifact is.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card