Effective 1 October 2026, GitHub Actions will apply the same retention policy that governs artifacts and logs to checks, workflow runs, and status records. The change collapses five separate data lifetimes into a single configurable window, defaulting to 90 days, and removes the historic 400‑plus‑day default for those three item types.
What the change covers
The retention setting, now labeled “Check, workflow run, status, artifact and log retention”, controls the lifespan of:
- Artifact files produced by a workflow
- Log output generated during execution
- Check results attached to commits or pull requests
- Workflow run metadata
- Status records (e.g., commit status APIs)
When the configured period expires, all five categories are purged together. The policy can be defined at the repository, organization, or enterprise level, but a repository cannot exceed the cap set higher up the hierarchy. Public repositories are limited to a maximum of 90 days for checks, runs, and statuses, matching the existing artifact/log ceiling.
Why it matters to engineers and operators
For AI, cloud, DevOps, and security teams, the primary impact is two‑fold: data freshness and cost predictability. Stale checks and run records will disappear once they outlive the artifact/log window, keeping the UI and API responses faster and reducing the storage footprint that feeds into GitHub’s billable Actions storage.
Because only artifacts and logs count toward storage charges, tightening the retention period can directly lower monthly costs. Conversely, extending the window retains more log data, which may increase the billable amount.
Operational and architectural implications
Retention planning: Teams should audit their current retention configuration before the October deadline. If a longer audit trail is required for compliance or debugging, the setting must be increased now, respecting the organization‑level cap.
Data archiving strategy: The purge is not retroactive; data already removed by the previous 400‑day rule cannot be restored by changing the setting. Practitioners needing long‑term evidence must export or archive checks, runs, or statuses before they are deleted.
Impact on CI/CD pipelines: Pipelines that rely on historic run data for metrics, trend analysis, or automated gating will see a reduced history window. Adjust any tooling that assumes indefinite availability of run metadata.
Security considerations: While the metadata itself is not billed, the associated logs may contain sensitive information. Shortening retention reduces the window in which such data is stored, potentially lowering exposure risk.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review the current Actions retention value for each repository, organization, or enterprise you manage. Verify that the period aligns with your debugging, compliance, and cost‑optimization goals. If you need a longer window, raise the setting now—up to the maximum allowed by your upstream caps (90 days for public repos). Export any run data you must keep beyond that horizon, because the automated cleanup will not restore it. Finally, monitor your Actions storage bill after the change; a tighter retention window should translate into lower storage charges, while a longer window will have the opposite effect.