GitHub Actions startup_failure / BuildFailed with zero jobs on private repository

[zhangruotian20030217-droid]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Repository: zhangruotian20030217-droid/realping-chatgpt-ai
Private repository.
GitHub Actions workflows suddenly started failing before any job is created.
Symptoms:

• conclusion = startup_failure
• path = BuildFailed
• workflow name is empty
• jobs = 0
• no runner is assigned
• no step logs are created
  Last known successful Actions run:
  35999066228
  First known startup failure:
  36036526263
  Recent representative failures:
  36204108315
  36204637280
  36204700052
  We verified:
• Actions are enabled
• “Allow all actions and reusable workflows” is enabled
• Billing budget is not exhausted
• Payment method is valid
• Existing production workflows previously ran normally
• Repository workflow permissions are enabled
• A brand-new minimal ubuntu-latest workflow containing only echo, uname, and python --version also fails before job creation
  Minimal probe commits:
  f53b272e339709cd44b76a3c034ef8df0847c466
  da482da9a76c20a8d546c4c7daa1a12cc5ffdac6
  The failure occurs before runner/job materialization, so this does not appear to be application code, Python dependencies, or workflow step execution.
  Could GitHub please investigate whether this repository has a stuck Actions workflow registry, job-graph construction issue, synthetic BuildFailed workflow state, or backend control-plane problem?
  Any guidance on how to force a repository Actions workflow registry reindex/reset would be appreciated.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[zhangruotian20030217-droid]

Update — 2026-09-26 23:07 Asia/Taipei
The issue is still ongoing.
From the 18:00 production window through 23:07, 11 additional GitHub Actions runs were created in this repository. Every one of them failed with the same pre-job signature:

• workflow name: empty
• path: BuildFailed
• conclusion: startup_failure
• jobs: 0
• workflow_id: 366298932
  Latest affected run:
• Run ID: 36249525846
• Created: 2026-09-26T14:44:25Z
• Event: push
• Head SHA: 1c4cbcfae14ab4d7abdf81d225a9865fe1583159
• Jobs: 0
  Scheduled production events are affected as well. Examples:
• Run 36234485614 — scheduled at 2026-09-26T10:00:48Z
• Run 36240480575 — scheduled at 2026-09-26T11:58:46Z
• Run 36246855047 — scheduled at 2026-09-26T13:57:08Z
  All of these also ended with:
  name = empty / path = BuildFailed / startup_failure / jobs = 0
  This means the failure occurs before any job graph is created. No runner is assigned and no workflow steps begin.
  We have already checked:
• repository Actions are enabled
• “Allow all actions and reusable workflows” is enabled
• billing/payment method is present
• Actions budget had not reached its configured limit when the issue was first investigated
• changing/re-registering a workflow did not resolve the issue
  At this point, could GitHub staff please investigate the repository-side/backend Actions registration or dispatcher state, especially the repeated synthetic BuildFailed entry associated with workflow_id 366298932?
  If there is a stale workflow registry/dispatch record for this repository, please advise whether it can be reindexed/reset from the GitHub side.
  Repository:
  zhangruotian20030217-droid/realping-chatgpt-ai
  Thank you.

[zhangruotian20030217-droid]

Final diagnostic update — billing root cause excluded
I have now verified the account billing state:

• GitHub Actions monthly budget: $15.00
• Current Actions spend: $10.47
• Remaining budget: $4.53
• Stop usage when budget limit is reached: enabled
• Budget limit reached: No
• A valid, non-expired payment method is configured
  Therefore billing/budget exhaustion is not the active blocker.
  The repository still produces:
• BuildFailed
• startup_failure
• jobs=0
• no hosted runner allocation
• no checkout
• no job logs
  Representative current failed run:
  36386193957
  Minimal ubuntu-latest smoke workflow also reproduces the same failure before job creation.
  Please escalate/investigate this as a GitHub Actions control-plane / job-creation / hosted-runner allocation issue for this account/repository.
  Repository:
  zhangruotian20030217-droid/realping-chatgpt-ai

[kurupdevs]

Your triage is thorough, and the minimal probe workflow failing the same way is the key data point: it has no uses: references at all, so broken reusable-workflow refs, bad YAML, and missing secrets are all ruled out. That leaves dispatcher/registry state on GitHub's side, exactly as you suspected.

One self-service reset you haven't tried yet: toggle Actions off and back on for the repository. Repo Settings → Actions → General → set "Disable Actions for this repository", save, then re-enable. That forces GitHub to rebuild the repo's workflow registration — the closest thing to the registry reset you're asking for. It doesn't delete workflow files or run history, it just stops dispatching while off.

Also worth a look: check the repo Audit Log between your last good run and the first startup_failure. If anything changed at the repo/org level right in that window (Actions permissions, a plan change, a disabled workflow), it would explain why every event since — push, schedule, minimal probe — lands on the same stuck workflow_id.

If the toggle doesn't clear it, this needs a support ticket with exactly what you've gathered: the stuck workflow_id 366298932, the run IDs, and the fact that a minimal ubuntu-latest echo workflow reproduces it. That combination tells support the dispatch path itself is broken for the repo, which they can clear from their side.

[deepjyoti-dev]

Oof, a startup_failure with zero jobs and no runner assigned right out of the gate is brutal, especially since you already checked all the obvious billing and workflow permission boxes. Given how specific those run IDs and commit hashes are, this definitely looks like a corrupted internal queue or registry state for that repo. Hope someone from the engineering team takes a look soon!