GitHub artifact retention changes future storage, not past GB-Hours

GitHub cut the retention clock. Yesterday’s artifacts kept theirs.

Why it matters

A repository owner shortens GitHub Actions artifact retention and expects storage usage to fall. The new setting governs artifacts created after the change. Older files keep their existing expiry dates, while storage hours already accrued remain on the bill. One control panel contains two clocks, and neither runs backward.

Mara Voss3 November 2026 at 10:56 UTCReading Time 2 minLast update: 3 November 2026

A shorter retention period governs new artifacts while stored files and accrued hours keep their earlier clocks.

Summary

GitHub’s default artifact and log retention is 90 days. Changing a repository’s retention period applies to newly created artifacts and logs; existing artifacts retain their scheduled expiry.
GitHub bills artifact storage beyond the included allowance by accrued GB-Hours. Deleting an old artifact stops future storage hours, but the hours already recorded in the billing cycle remain.

The setting changed. The old crates stayed on the shelf.

An engineering manager finds a long retention period and cuts it. The save succeeds. New workflow artifacts will follow the shorter window. The stock already sitting in GitHub’s storage keeps the dates it received when it was created. If the goal was to reduce today’s inventory, a settings change alone leaves that work unfinished.

GitHub’s own documentation makes the split explicit. Repositories normally retain artifacts and logs for 90 days. Public repositories can set one to 90 days; private ones can set one to 400 days, subject to wider organization limits. A changed period applies only to new objects. A team can inspect each existing artifact’s expires_at through GitHub’s API and remove artifacts that it has decided no longer need to be kept. Deletion is permanent, so the release, audit or incident value of the file belongs in that decision.

The billing meter runs on a second clock. GitHub measures artifact storage by the hour, in GB-Hours, for usage above the plan’s included allowance. Current storage and accrued storage are different numbers. When an old artifact is deleted, current storage falls and future hourly accumulation stops. Earlier hours remain in the current billing cycle. GitHub’s worked example holds 10 GB for ten days and deletes it on day eleven; the ledger still contains 2,400 GB-Hours. That is an illustration from GitHub, not a customer invoice.

The interface can take six to twelve hours to update its artifact storage usage figures. An immediate reading after cleanup may therefore lag the underlying action. The operator needs three views: which old artifacts remain, what their expiry dates are, and how many storage hours the billing cycle has already accumulated. Artifacts share their included storage pool with GitHub Packages; Actions cache has a separate allowance and belongs to a different calculation.