Orphaned "BuildFailed" workflow (deleted state) intercepts all events — no jobs start repo-wide

[beathub-Official]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Every Actions event in my repository produces a startup_failure run with 0 jobs, and no real
workflow ever starts. This is repo-wide, not a broken YAML file. Posting in case anyone has seen
this, and because it looks like a registry-side defect rather than something self-serve.

The orphan

GET /repos/{owner}/{repo}/actions/workflows/344860610 returns:

• name: "" (empty)
• path: "BuildFailed"
• state: "deleted"
• created_at: 2026-08-28T21:00:56+02:00

It does not appear in GET /actions/workflows. PUT .../disable returns 403 "Unable to disable a
workflow that is not active". DELETE returns 404. No file named BuildFailed exists anywhere in
the repo, though GitHub exposes a blob URL for it that 404s.

The record was created in the same second as an ordinary push. There was no workflow file change in
that commit.

What I've ruled out

• .github/workflows/ is byte-identical between the default branch and the feature branch (same git
  blob SHAs). Three normal workflows are registered and visible in the sidebar.
• No rulesets, no branch protection, no required workflows.
• Actions enabled, all actions allowed, no spending limit message. Failure happens before any job is
  created.
• No workflow_run triggers in the repo (I saw a similar report caused by a malformed workflow_run
  glob — that isn't this).
• Not billing. Failures are pre-job with 0s / -1s durations.

Why the usual workaround doesn't apply

The documented fix for a single wedged workflow is to copy it to a new file path so a fresh entity
registers. I created a brand-new 12-line workflow at a new path on the default branch containing
only an echo step. New entity registered, and the run still fails at startup with 0 jobs.

A workflow with no dependencies and one echo step cannot start. That suggests the whole repository's
dispatch is affected rather than one workflow entity.

Also tried without success: close/reopen PR, disable and re-enable Actions, empty commit, renaming
the CI workflow, workflow_dispatch on the real CI workflow, and re-running a previously green run
(that rerun also failed at startup and overwrote the green record).

Timeline

Last healthy run was 2026-08-28T10:41:59Z. Everything after 21:00:56 that day fails. There were
Actions incidents on 26–27 Aug; this appeared after those were marked resolved, which makes me
suspect leftover trigger-database state.

I filed a support ticket with all of this and it was auto-closed by a virtual assistant pointing at
self-service resources, so I'm posting here.

Has anyone seen an orphaned workflow record in deleted state intercepting dispatch like this, and
is there anything self-serve I've missed?

[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. ⭐

[0xmarkhydra]

Another confirmed case on a private repository under this account. Every push/PR is intercepted before job creation by an orphan workflow registration with the exact same signature:\n\n- workflow_id: 345106030\n- path: BuildFailed\n- name: empty\n- state: deleted\n- created_at: 2026-08-29T11:20:25+07:00\n- conclusion on generated runs: startup_failure\n- jobs/check-runs: 0\n\nI ruled out repository YAML and runner configuration with a minimal echo-only workflow, GitHub-hosted and self-hosted runners, and actionlint. I also purged all 594 runs belonging to the orphan ID; the workflow endpoint temporarily returned 404, but the same workflow ID re-materialized on the next event. Disabling Actions, purging the orphan run, re-enabling Actions, and triggering a fresh event produced the same result again.\n\nThis appears to require a backend purge/reindex of the orphan workflow registration. If GitHub staff need the private repository or run URLs, I can provide them through a private support channel. Please correlate this account with workflow_id 345106030 and remove/reindex the stuck BuildFailed registration.

[tomm1990]

you’ve already done the hard part. this isn’t a bad workflow file.

path: "BuildFailed" + state: "deleted" + empty name, created in the same second as a normal push, then every event (including a brand-new echo-only workflow at a new path) dying as startup_failure / 0 jobs means the repo’s Actions dispatch/registry is poisoned. copying a workflow to a new path only helps when that one entity is wedged - it can’t help when the ghost BuildFailed record is intercepting the whole repo.

@0xmarkhydra’s note seals it: purge all runs for the orphan id → endpoint briefly 404s → same workflow id comes back on the next event. disable Actions → purge → re-enable → same. so the self-serve loops people keep suggesting (rename yaml, empty commit, re-run green, wipe runs) won’t stick here.

what’s left:

1. stop re-running old greens / spamming new workflow paths - you’re just burning history and confirming the same failure
2. escalate support (or reopen the auto-closed ticket) with a tight packet, not a novel:

pattern: orphan workflow path=BuildFailed state=deleted name="" 
repo: <owner/repo> (private)
workflow_id: 344860610   # beathub
# and/or 345106030       # 0xmarkhydra account
last healthy run: 2026-08-28T10:41:59Z
first broken:     2026-08-28T21:00:56+02:00
symptoms: startup_failure, jobs=0, pre-job, all events
tried: new-path echo workflow, disable/enable Actions, empty commit,
       rename CI, workflow_dispatch, re-run green, delete orphan runs
       (orphan id rematerializes after delete)
need: backend purge/reindex of the BuildFailed registration

3. if you need CI today while waiting: mirror/push the same workflows to a clean throwaway repo under the same org (or a fork you control) and run there - ugly, but it bypasses this repo’s registry row.

[phoenixxrising88]

I am seeing the same failure signature on a separate private repository, phoenixxrising88/phoenix-operations-hub, and it has persisted across many unrelated commits, branches, PRs, workflow changes, GitHub-hosted validation attempts, and a repository-level self-hosted Windows runner.

Repository

phoenixxrising88/phoenix-operations-hub

Orphaned workflow record

workflow_id: 342415861
name: ""
path: BuildFailed
state: deleted
created_at: 2026-08-25T16:33:31-04:00

Direct API lookup of that workflow ID returns the deleted record, but the normal workflow collection contains only the legitimate active workflows.

The legitimate registered workflows are:

Validate
E2E Readiness
Desktop Validate
Desktop Installer Artifact
Deploy Production

There is no BuildFailed file in the repository.

Current reproduction

Release-candidate commit:

083791070b2d030f2cdcd03526b1fbe76fa764e3

Two recent PR-triggered runs on that exact commit:

run 33690649075
workflow_id 342415861
name ""
conclusion startup_failure

run 33690632646
workflow_id 342415861
name ""
conclusion startup_failure

Querying the jobs for run 33690649075 returns:

{
"jobs": []
}

So the failure occurs before job creation, runner matching, checkout, dependency installation, or execution of any workflow step.

Independent self-hosted runner test

I added a repository-level Windows runner named Phoenix-Hub-Deploy.

The runner was online and idle. A dedicated validation workflow was created specifically for:

self-hosted
Windows
X64

PR: phoenixxrising88/phoenix-operations-hub#1189

That did not change the failure mode. GitHub still created the synthetic/deleted BuildFailed startup failure before any job was scheduled to the runner.

This appears to rule out both GitHub-hosted runner availability and self-hosted runner registration as the cause.

Historical control proving this repository previously scheduled jobs normally

Earlier workflow run:

32845754987

successfully created job:

97794910327

and executed:

Set up job success
Check out repository success
Set up Node.js success
Install dependencies success
Test failure

That was a normal application/test failure. The important distinction is that GitHub successfully created and scheduled the job.

The current BuildFailed condition never reaches that stage.

Persistence

This has not been confined to one PR or one malformed commit. The repository has documented zero-job startup_failure behavior across unrelated development work since late August.

For example, the current final release-candidate PR explicitly remains blocked because GitHub Actions cannot create jobs:

phoenixxrising88/phoenix-operations-hub#1191

The repository also contains historical documentation from August 28 identifying the condition as repo-wide and occurring before workflow configuration/job execution:

commit dcca10f6b2ad5f1a59075083c90a47e44ea4d118

What has already been ruled out

Workflow code itself
Individual workflow name/path
PR-specific failure
Application tests
GitHub-hosted vs self-hosted runner
Runner registration/matching
Checkout
Dependencies
Node setup
Workflow job execution

A manual workflow_dispatch fallback was also added previously to the legitimate Validate workflow specifically to bypass PR-event scheduling issues. It did not resolve the underlying synthetic BuildFailed behavior.

Support ticket

GitHub Support ticket #4722758 included the workflow record, failed run, zero-job API response, active workflow list, and self-hosted runner evidence.

Support closed the ticket because the support resources available to the account are Community Discussions, Docs, and Skills. There was no technical diagnosis or backend repair.

What appears to require GitHub intervention

The persistent object is workflow ID:

342415861

with:

path = BuildFailed
state = deleted
name = ""

yet new workflow runs continue to resolve to that workflow ID.

Is there any supported self-service mechanism to purge/reindex this deleted workflow registration or the repository's Actions trigger/dispatch state?

If not, could this case please be correlated with the other reports in this discussion and escalated to the GitHub Actions team?

I can provide additional run IDs/API output if useful, but I have intentionally excluded credentials, secrets, and private source code.

[erimes84]

We're seeing what appears to be the same issue in another private repository.

Repository: erimes84/ViradaFs

Our previously healthy workflow was:

• workflow_id: 348754866
• path: .github/workflows/ci.yml
• successful run: 33678517361

All new push and pull_request events are now being intercepted by:

• workflow_id: 348819625
• path: BuildFailed
• name: empty
• conclusion: startup_failure
• jobs: 0

We already tried:

• confirming self-hosted runners are online and Idle;
• disabling and re-enabling GitHub Actions;
• confirming Allow all actions and reusable workflows;
• pushing new commits after re-enabling Actions;
• creating a completely new branch and Draft PR with only a Markdown file and no workflow changes.

The isolated PR reproduced the exact same failure:

• PR: #198
• run: 33692832336
• workflow_id: 348819625
• jobs: 0

Our own report is here:
https://github.com/orgs/community/discussions/206626

This looks like the same orphaned BuildFailed workflow registration issue. If GitHub staff are tracking these cases, our repository likely needs the same backend purge/reindex.

[Oussamanakhil]

Confirmed the same repository-wide backend signature on a second private repository.

Repository: Oussamanakhil/berbernest-studio

• Orphan workflow ID: 349512914
• Name: empty
• Path: BuildFailed
• State: deleted
• Active workflow ID: 349512897
• Active workflow path: .github/workflows/ci.yml

Every push and manual dispatch ends in startup_failure before any job is created. The orphan was created two seconds after the valid workflow registration and is not returned by the normal workflow list.

Repository-side checks exhausted:

• YAML lint and actionlint both pass
• separate one-step workflow fails before job creation
• self-hosted runner label also fails with zero jobs, ruling out hosted-minute allocation
• deleted all orphan runs; GitHub recreated the same deleted workflow record
• disabled and re-enabled Actions
• changed the default branch and restored it
• registered the workflow under a new file path and workflow ID
• reclaimed the BuildFailed name with a valid workflow and removed it again

Example valid-workflow manual dispatch failure: https://github.com/Oussamanakhil/berbernest-studio/actions/runs/33949656979

Latest orphan-intercepted push: https://github.com/Oussamanakhil/berbernest-studio/actions/runs/33950418744

All temporary workflows and branches were removed and the canonical workflow restored. This now appears impossible to repair through repository APIs. Could GitHub staff purge orphaned workflow registration 349512914 server-side?