Unmasking Ghost Storage: Boosting Software Developer Efficiency in GitHub Actions

The Phantom Quota: Understanding GitHub Actions Storage Anomalies

A recent discussion on the GitHub Community forum highlighted a perplexing issue: an organization hitting its GitHub Actions storage quota despite not running any actions for months and having artifact expiration configured. This scenario, initially raised by user jefflongo, points to a common pitfall that can hinder software developer efficiency and lead to unexpected costs.

Jefflongo reported receiving an email about nearing their Actions storage quota, with usage reports showing ~45 gigabyte-hours per day from a single repository. The puzzling part? This repo hadn't run any actions in over 10 months, and its few old workflow runs had artifacts that were explicitly set to expire in one day and were indeed marked as expired.

Why Expired Artifacts Still Count

The community quickly chimed in with explanations, revealing a nuanced picture of GitHub Actions storage:

• Delayed Cleanup: Even with expiration policies, GitHub's background cleanup processes might not immediately purge artifacts, logs, and caches. There can be a delay between an artifact being marked 'expired' and its physical deletion from storage.
• The 'Ghost File' Glitch: As BryanBradfo pointed out, there's a known backend issue where GitHub marks artifacts as "expired" in the UI but fails to delete the actual files from the server. This means the billing system continues to count these "ghost files" against your quota, directly impacting your organization's developer productivity tools and budget.
• Beyond Artifacts: Storage quota isn't just for artifacts. Workflow logs, caches, and other metadata associated with runs also consume space. These might persist even after artifacts are gone or marked expired.

Immediate Solutions for Reclaiming Space

When faced with this phantom storage usage, the community offered clear, actionable steps to restore your software developer efficiency:

• Manual Deletion of Workflow Runs: The most direct solution is to manually delete the old workflow runs. This action forces the system to remove associated artifacts, logs, and metadata, effectively clearing the "ghost files." You can do this via the Actions tab in your repository settings.
• Leverage GitHub CLI for Bulk Deletion: For repositories with numerous old runs, using the GitHub CLI (Command Line Interface) can be a more efficient way to bulk-remove stale workflow data. This is a powerful tool for managing your development productivity tools.
• Allow Time for Recalculation: After deletion, it's crucial to wait 6-24 hours for GitHub's storage recalculation to complete. Your usage should drop once the system recognizes the deletions.

Proactive Strategies for Future Efficiency

To prevent recurrence and maintain optimal software developer efficiency, consider these long-term strategies:

• Aggressive Organization-Level Retention Policies: Implement strict artifact and log retention policies at the organization level (Organization Settings → Actions → General). This ensures consistency and prevents individual workflows from accumulating excessive data.
• Alternative Storage for Large Outputs: For very large build outputs or long-term archives, consider using alternative storage solutions like GitHub Releases (for binaries) or external cloud storage (e.g., AWS S3, Azure Blob Storage).
• Understand Time-Weighted Billing: Remember that artifact storage billing is based on time-weighted usage, not just point-in-time snapshots. Deleting artifacts stops future accrual but doesn't retroactively erase the storage already consumed.

By understanding these nuances and implementing proactive management strategies, organizations can avoid unexpected storage costs and ensure their GitHub Actions workflows contribute positively to overall software developer efficiency.