Actions storage quota stuck at 100% after Packages purge — all workflows failing at startup

[974jeff]

Account / repo

• Account: 974jeff (GitHub Free)
• Repository: 974jeff/MAKATYIS (private)

Symptom

All GitHub Actions workflow runs for this repository fail at startup (conclusion=startup_failure) with 0 jobs executed. The CLI message is the generic “This run likely failed because of a workflow file issue.” Workflow YAML is unchanged and previously succeeded.

• First failure: 2026-08-15 18:10:06 UTC (example: unnamed/BuildFailed run after SHA eeca2e67)
• Still failing as of 2026-08-16 13:04:41 UTC
• Elapsed at time of this post: ~20 hours (documented 6–12 hour billing recalculation window exceeded)

Example runs (all startup_failure, 0 jobs):

• https://github.com/974jeff/MAKATYIS/actions/runs/31925339753 (push)
• https://github.com/974jeff/MAKATYIS/actions/runs/31926446687 (workflow_dispatch, named Railway Monitor)
• https://github.com/974jeff/MAKATYIS/actions/runs/31926544175 (workflow_dispatch, same)
• https://github.com/974jeff/MAKATYIS/actions/runs/31948806808 (workflow_dispatch, 2026-08-16 13:04:41 UTC)

Last successful named workflows: SHA 4717608 at 2026-08-15 17:59:27 UTC (about 11 minutes before the first startup_failure).

What we measured after cleanup

GitHub Packages (GHCR) container makatyis:

• Deleted 723/723 untagged versions on 2026-08-15 ~16:38–17:20 UTC (API, 0 delete failures)
• Tag :latest preserved (version id 1136520837, digest sha256:8ad953c4…)
• Four additional untagged versions created by a later successful build were deleted 2026-08-16 morning UTC; :latest still 1136520837
• Packages API now lists 1 version (:latest only)

Shared Actions artifacts + Packages storage (Free 500 MB pool), measured from Packages/API after purge: ~297 MiB (~59%) — GHCR ~139.6 MiB + artifacts ~157.5 MiB. This is well below the 500 MB included quota. The billing UI snapshot still appeared stuck at 100% / 0.5 GB when workflows started failing.

What we already tried

• Waited longer than the documented 6–12 hour usage recalculation window (now ~20 hours since first startup_failure)
• Several spaced workflow_dispatch probes without additional commits (runs listed above) — still startup_failure
• Did not change workflow YAML (last green run used the same files)

This does not match a current GitHub.com incident: githubstatus.com reported All Systems Operational (Actions and Packages operational) at 2026-08-16 14:28 UTC.

Request

Please manually refresh the Actions/Packages storage billing snapshot for account 974jeff / repo 974jeff/MAKATYIS, or confirm the actual delay we should expect if it can exceed the public 6–12 hour documentation.

Happy to provide GHCR version ids or billing screenshots if useful.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[hoangperry]

Two separate mechanics are stacking on you here, and knowing both explains the "stuck at 100%":

1. The usage meter is not real-time. Storage billing for Actions artifacts and Packages is computed periodically (hours-scale, and the billed figure is even calculated as a monthly average) — deletions don't move the "% used" display immediately. So a purge done yesterday can legitimately still show 100% today while the recalculation catches up. Nothing you did failed; the meter lags.
2. Packages may not have been the real consumer. The quota that blocks workflow startup covers shared storage — and in most "suddenly at 100%" cases the space is actually in Actions artifacts and caches, not packages. Check the breakdown at Settings → Billing → Usage, then clean the right thing: artifacts via gh api repos/974jeff/MAKATYIS/actions/artifacts --paginate (delete old ones), caches via gh cache list -R 974jeff/MAKATYIS / gh cache delete.

And the practical unblock while the meter refreshes: set a small spending limit (Settings → Billing → Budgets/spending limit — requires a payment method). The startup block applies when you're at quota with a $0 limit; even a $1 limit lifts the hard stop immediately, and you can drop it back to $0 once the recalculated usage falls under quota. If the meter still shows 100% more than ~48h after the storage genuinely went below quota, that's a billing-sync bug for https://support.github.com — include the usage-page screenshot and the deletion timestamps.

[974jeff]

Follow-up from the account owner (974jeff).

The startup_failure was not a delayed Actions/Packages storage recalculation.

A later push run showed the actual blocker in the log: recent account payments have failed or spending limit needs to be increased.

Payment / spending limit was corrected on the account. A single workflow_dispatch of Railway Monitor then completed success:
https://github.com/974jeff/MAKATYIS/actions/runs/31956220342
(2026-08-16, SHA 43c6c99c).

The GHCR/Packages purge remains useful hygiene; it was not the cause of this outage. Sorry for the incorrect initial diagnosis in this thread.