GitHub Actions workflow ends in startup_failure before job creation

[jhonf463r]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I'm seeing a GitHub Actions startup issue in a private repository. A workflow run completes with conclusion startup_failure, and the Jobs API returns an empty list. There is no job ID, runner name, step record, or downloadable job log. In the run metadata, the workflow association has an empty workflow name and a path shown as BuildFailed; a prior read reported the associated workflow record as deleted.

Repository-level Actions settings were previously checked through an authenticated read-only session and reported as enabled with all actions allowed. A read-only query to the repository Actions usage endpoint returned HTTP 404 and no usage values, so usage/budget status is unknown—not confirmed blocked or unblocked. Related hosted Windows and Ubuntu runs also stopped before executing steps. No test suite ran, and no further runs have been attempted after this diagnosis.

Which documented troubleshooting checks are appropriate for a startup_failure with zero jobs and no job logs? Is there a supported diagnostic path for an unexpected workflow metadata/dispatch state in a private repository?

[iamswayam]

Hey jhonf463r,

This is a really nasty edge case. When a run dies with startup_failure, an empty jobs list, and that weird synthetic BuildFailed path, it usually means the GitHub Actions orchestration engine crashed or blocked the workflow before it could even parse your YAML file or pass the job to ARC.

Since your repo settings are wide open, here are a few things that cause this exact backend blind spot:

1. The Billing / Spending Limit Block (Most Likely)
   Even if your repo permissions say "All actions allowed," a silent billing freeze will immediately drop runs and cause that 404 on the usage endpoint. If this is a personal repo or under an org namespace, have the owner check Settings -> Billing and plans -> Spending limits. If the limit hit $0 or the free monthly minutes for private repos ran out, GitHub kills the run at the front door before creating a Job ID.

2. Orphaned Workflow Indexing Bug
   The BuildFailed / deleted metadata state implies GitHub's internal database routing map for this specific workflow file got corrupted. The dispatcher thinks it's triggered, but when it looks for the file, it hits a dead end.

• To test this, try creating a completely new dummy workflow file (e.g., test-clear.yml) with a simple workflow_dispatch trigger and a single echo step. Push it to a new branch and try running it. If it works, the engine's pointer for your original workflow file is stuck, and renaming/re-creating the original file usually fixes it.

3. ARC App / Token Expiration
   Since you're using ARC, if the workflow somehow passes the internal checks but fails right at the handoff, double-check the controller logs in Kubernetes. If the GitHub App credentials or Personal Access Token (PAT) used by ARC recently expired or lost repository permissions, the runner registration pool will reject the backend requests.

If the billing looks clean and a brand-new workflow filename still causes a 404 on the usage endpoint, you're likely dealing with a stuck database state on GitHub's side. You'll probably need to open a support ticket to have a backend engineer clear the stuck routing key.

Let me know if trying a completely new workflow filename changes the error!

[jhonf463r]

Update after additional read-only checks on October 26, 2026:

The authenticated Billing & Licensing summary shows GitHub Free and Copilot Free, with no visible subscription, balance, or billing alert explaining the restriction. The authenticated GitHub Actions page continues to display this warning: "Your account's billing is currently locked." The run list shows repeated failures at startup, and recent run metadata has an empty jobs list, so there is no evidence that project tests executed.

This leaves a verified discrepancy between the Billing & Licensing summary and the Actions page; the underlying cause of the restriction remains unknown. I also inspected the official GitHub Support billing flow, but the Free-account contact path reached a form without a subject or description field, and no support ticket was created.

Is there a supported escalation path for an account-level Actions billing lock when Billing & Licensing shows no issue? I am not creating dummy workflows or changing billing settings merely to test a hypothesis.