GitHub Actions run remains queued without creating any jobs

[mario-roemer]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner

Discussion Details

On a personal GitHub Free account, a push-triggered workflow in a private repository has remained queued for more than one hour. It has one job on the standard ubuntu-latest runner.

Both the run's jobs endpoint and the attempt-specific jobs endpoint report total_count: 0. The workflow has no concurrency group, needs dependency, environment approval gate, or matrix. Actions are enabled for the repository, and there is no in-progress push workflow in that repository. I have not established whether an account-wide concurrency restriction is involved.

The billing overview shows that the included compute and storage allowances are not exhausted and billable Actions usage is zero. A zero-dollar paid Actions budget is marked Usage blocked. I do not know whether that flag is relevant while included usage remains available. GitHub Status reports Actions as operational.

No cancellation, rerun, new workflow dispatch, workflow change, budget increase, or new runner has been attempted.

How can I identify why the workflow is waiting before any job is created, without restarting it? Is there a supported way for a Free account to request investigation of a potentially stuck run or an account-level hold?

[erkangcmn]

First thing to check is when the run was created. On Nov 11, GitHub had an incident affecting Actions (https://www.githubstatus.com/history), and runs that got queued roughly between 20:15 and 20:45 UTC were left orphaned: queued, total_count: 0 jobs, and they never start. Other people saw exactly this at the same time (#212754, #212788, #212795). You posted at 22:01 UTC after it had been queued for over an hour, so your run very likely falls in that window.

You can confirm without touching the run:

gh api repos/OWNER/REPO/actions/runs/RUN_ID --jq '{created_at, status, run_started_at, check_suite_url}'
gh api "$(gh api repos/OWNER/REPO/actions/runs/RUN_ID --jq .check_suite_url)" --jq '{status, conclusion}'

If created_at is inside the incident window and the check suite is also stuck in queued, that's the orphaned state. There's no further diagnostic info exposed for it. It's on GitHub's side.

About the $0 budget marked "Usage blocked": that budget only applies to paid usage beyond your included allowance. As long as your included minutes aren't used up, it doesn't block runs on GitHub-hosted runners, so it isn't the cause here.

What you can do:

• Investigation: Free accounts can open a ticket at https://support.github.com/contact (choose Actions). Include the run ID and created time. Support can check for an account-level hold and clear the stuck run. Cancelling it yourself will most likely return a 409, like it did for others.
• Checking that Actions works again: whenever you're OK with it, push a new commit or run workflow_dispatch. If the new run starts normally, the old one was just an incident leftover. If it also sits at zero jobs, mention that in the ticket, because then something else is going on.

[xecrets]

So...

I followed all the available documentation all the way to a force cancel via the API. No joy. 409.

Went to support, followed all the instructions, detailed the problem and what I had done, and submitted a ticket.

A few milliseconds later I got response from Noah (Virtual Assistant):

Thank you for reaching out to GitHub Support. After reviewing your account and the nature of your request, the support resources currently available to you are:

GitHub Community Discussions
GitHub Docs
GitHub Skills
Because these support options are self-service resources, we'll be closing this ticket at this time. We understand this may be disappointing, and we encourage you to explore those resources, as they often provide helpful guidance and next steps.

Very helpful! Not. Welcome to the age of AI non-support.

[erkangcmn]

Ugh, sorry, that's on me. I didn't know Free-plan tickets for Actions get auto-closed like that. Thanks for posting it, it's useful for everyone landing here.

So on a Free account the realistic options are:

• Ignore the stuck run. It never got any jobs, so it doesn't run anything or use minutes. Unless your workflow has a concurrency group, it doesn't block new runs either. A new push or workflow_dispatch should start normally.
• It should eventually go away on its own. GitHub's documented limit for a workflow run is 35 days including waiting time, and runs that hit it get cancelled (see "Workflow run time" in Actions limits). I can't promise that also applies to these orphaned runs, but you don't need to wait for it anyway, since it only clutters the run list.
• Leave a note on this thread with your run ID and created time, so GitHub staff can see more runs are affected when they go through incident leftovers.

[xecrets]

Hi!

Ugh, sorry, that's on me.

No problem. Just very annoying. The AI could have told me that up-front instead of making me go through all the motions and then auto-closing it. It already knew everything when it told me to submit the ticket.

Leave a note on this thread with your run ID and created time, so GitHub staff can see more runs are affected

Run started at Nov 11, 9:28 PM GMT+1. Repo https://github.com/xecrets/xecrets-mobile, run ID 43096241677.

gh api --method POST repos/xecrets/xecrets-mobile/actions/runs/43096241677/force-cancel
{
  "message": "Cannot cancel a workflow run that has not been queued yet.",
  "documentation_url": "https://docs.github.com/rest/actions/workflow-runs#force-cancel-a-workflow-run",
  "status": "409"
}

[erkangcmn]

Thanks for adding the details! 20:28 UTC lands right in the incident window, so it's the same issue. Good news is every run in your repo since then (21:39, 22:19, 03:23, 08:40 UTC) completed successfully, so the stuck one isn't blocking anything. It's just a leftover sitting in the list.

[Praveen-Suthar-08]

This is most likely the Nov 11 Actions incident leaving orphaned runs. Runs created roughly between 20:15 and 20:45 UTC were left in queued with total_count: 0 jobs and never started. Several other reports show the same symptoms (#212754, #212788, #212795). The cause is on GitHub's side, not in your workflow, concurrency settings or billing.

How to confirm without touching the run

gh api repos/OWNER/REPO/actions/runs/RUN_ID --jq '{created_at, status, run_started_at, check_suite_url}'
gh api "$(gh api repos/OWNER/REPO/actions/runs/RUN_ID --jq .check_suite_url)" --jq '{status, conclusion}'

If created_at is inside the incident window (see https://www.githubstatus.com/history) and the check suite is also stuck in queued, it's the orphaned state. The API doesn't expose any more detail than that.

Your other questions

• "Usage blocked" on the $0 budget: not the cause. That budget only limits paid usage beyond your included allowance. While included minutes remain, GitHub-hosted runners are not blocked.
• Account-wide concurrency: not a factor. A run with zero jobs is not holding any runner slot or counting toward concurrency.
• Requesting investigation: Free-plan Actions tickets at https://support.github.com/contact can be auto-closed, so don't count on them. The most useful step is to post your run ID, repository and created time in this thread so GitHub staff can see which runs were affected.

What to do now

1. Ignore the stuck run. It has no jobs, uses no minutes, and without a concurrency group it won't block new runs. Cancel and force-cancel will probably return 409 because the run never started.
2. When you're ready, push a new commit or trigger workflow_dispatch. If the new run starts normally, the old one was just an incident leftover. If it also sits at zero jobs, that is a different problem, so report both run IDs.
3. Runs are capped at 35 days including waiting time, so it should be cleaned up eventually, though I can't confirm that applies to orphaned runs.