As of September 24, 2026, expired GitHub Actions artifacts are no longer shown in a workflow run summary and are no longer returned by the REST endpoints highlighted by GitHub for listing repository artifacts and retrieving an individual artifact. Previously, the record could remain visible with an expired indicator even after the underlying files had already been removed from storage.
This is a display and query change, not a retention-policy change. GitHub states that it does not change retention settings or billing. For teams that used the UI or API responses as a historical inventory, however, there is a practical consequence: the absence of an expired artifact is now expected behavior in those query surfaces.
What changed in the GitHub Actions interface
On a workflow run summary, the artifact list no longer shows items whose retention period has ended. The previous behavior kept the artifact name visible with an expired indication even though the files had already been deleted from storage.
This removes an important visual ambiguity. Seeing an item marked as expired could suggest that some stored object still existed or that the artifact was still contributing to storage usage. According to GitHub's announcement, the change was made specifically to remove that uncertainty.
What changes in the REST API
GitHub names two endpoints as directly affected: List artifacts for a repository and Get an artifact. Expired artifacts are no longer returned by these queries.
In practice, integrations that treated expired records as part of a historical inventory should be reviewed. A routine that enumerated artifacts and then filtered records by expired state may stop finding those records because the filtering now happens before the response reaches the consumer.
What should not be inferred
The announced change should not be interpreted as a broad change to all workflow data or as additional deletion triggered by the API. The confirmed point is that already expired artifacts, whose files no longer existed in storage, are no longer displayed or returned in the locations named by GitHub.
How to review automations that query artifacts
The main risk is in scripts, dashboards, and integrations that assume an expired artifact will remain available as a queryable record. Review workflows that:
- count expired artifacts to build historical metrics;
- use the API listing to reconstruct everything a run produced;
- trigger cleanup based on records marked as expired;
- compare the API total with older inventories and treat differences as failures;
- depend on the presence of an expired artifact to distinguish “never existed” from “existed and expired.”
For these cases, the logic should be adjusted so that absence from the UI or the named endpoints is not treated as proof that the artifact was never created.
Where to find history after expiration
GitHub says that if you need to know which artifacts a workflow run produced after they have expired, that information can still be found in the run logs. This makes logs a more important reference for retrospective auditing when the goal is to confirm that a specific artifact was generated.
There is an important operational distinction: logs may record that the artifact was produced, but they do not restore the expired file. GitHub documentation treats expiration as automatic removal of the artifact according to the applicable retention policy.
Retention is still configured separately
By default, GitHub documents a 90-day retention period for artifacts and logs generated by workflows unless a different setting applies at the repository, organization, or enterprise level. A custom period can also be defined for an individual artifact through retention-days in actions/upload-artifact, subject to the upper limits set by the account policy.
Therefore, the September 24 change is not an automatic reduction in retention time. It changes what is shown after expiration has already happened.
The change does not alter storage billing
GitHub's announcement explicitly states that the change does not modify billing. The billing documentation explains that Actions storage is accrued over time and that deleting artifacts lowers current storage and stops future charges associated with that storage, while usage already accrued in the billing cycle remains recorded.
This helps interpret the new interface correctly: no longer seeing an expired artifact is not a new cost-saving mechanism introduced by this change. Financial impact remains tied to storage actually retained and the billing rules, not to whether the record is visible on screen.
Review checklist for teams
- Check whether any script expects expired artifacts from the endpoints named by GitHub.
- Review metrics that use the number of returned artifacts as a historical time series.
- Do not classify an artifact as “never created” only because it no longer appears after expiration.
- Use run logs when you need retrospective evidence of which artifacts were produced.
- Check the retention policy configured at repository, organization, or enterprise level when the issue is storage duration rather than visibility.
- Separate billing diagnostics from listing diagnostics: the new hiding behavior does not change the billing policy.
What changes for security and reliability reviews
For development and security teams, the main implication is observability. Internal tools that used the API as a historical source may now have expected gaps after expiration. This requires distinguishing among states that were previously easier to infer from the listing itself: artifact available, artifact expired, and artifact with no visible record.
After the change, distinguishing “expired” from “never existed” may depend on other evidence, especially run logs or data the organization persisted before expiration. If that history matters for audits, incident investigations, or build traceability, the review should happen before retention removes the artifact from the listing.
