Deleted workflow still generating startup_failure runs on every push — how to remove ghost workflow?

[ecucondorSA]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

Problem

Every push to my repository triggers a startup_failure run from a ghost/deleted workflow named BuildFailed.

Repository

ecucondorSA/Autamedica (private repo)

Details

• Ghost workflow ID: 240241003
• • Workflow path: BuildFailed (the file no longer exists in the repo)
• • State: deleted (confirmed via GitHub API)
• • Effect: Every single push generates a startup_failure run attributed to this workflow, cluttering the Actions history

How it was created

On March 1, 2026, a malformed YAML was accidentally pushed to .github/workflows/. The file was deleted immediately, but the workflow entry persisted in GitHub's backend with state: deleted. Since then, every push creates a new startup_failure run.

What I've tried

• Confirmed the file does not exist in the repo: git ls-files .github/workflows/ shows no BuildFailed file
• • Confirmed via API: curl -H "Authorization: Bearer TOKEN" https://api.github.com/repos/ecucondorSA/Autamedica/actions/workflows returns the workflow with "state": "deleted"
• • Deleted and recreated .github/workflows/ directory — problem persists

Request

Please permanently remove workflow ID 240241003 (BuildFailed, state: deleted) from the repository's workflow list so it stops generating startup_failure runs.

Thank you!

[Radi410]

You need to delete every single run associated with that specific ID (240241003). You can do this quickly with the GitHub CLI:

Bash
Replace with your actual repo details
gh run list --workflow=240241003 --limit 1000 --json databaseId -q '.[].databaseId' | xargs -I{} gh api -X DELETE /repos/ecucondorSA/Autamedica/actions/runs/{}
Once the last run is deleted, the workflow entry usually disappears from the sidebar and the API within a few minutes.

If deleting the runs doesn't stop the new ones from appearing, GitHub likely has a "hook" stuck on the name BuildFailed.

Create a new valid workflow file at .github/workflows/BuildFailed.yml.

Give it a different internal name, like name: Ghost Buster.

Push this to your main branch.

This "re-claims" the path and name in the indexer with a valid configuration.

Once it successfully runs (or at least shows up as active), disable it via the UI first, then delete the file again.

If the ghost persists, you can force a full re-index of the repository's Actions state:

Go to Settings > Actions > General.

Select Disable Actions and save.

Wait about 5-10 minutes (this allows the backend caches to clear).

[aarav-g-168]

delete all runs tied to the ghost workflow ID

WORKFLOW_ID=240241003
REPO="ecucondorSA/Autamedica"

gh run list --repo "$REPO" --workflow "$WORKFLOW_ID" --limit 1000
--json databaseId -q '.[].databaseId'
| while read run_id; do
echo "Deleting run $run_id"
gh api -X DELETE "/repos/$REPO/actions/runs/$run_id"
done

echo "Done. Give it a minute or two for GitHub to update."

optional: trigger a fresh index by temporarily disabling actions

gh api -X PUT "/repos/$REPO/actions/permissions" -f enabled=false
sleep 30
gh api -X PUT "/repos/$REPO/actions/permissions" -f enabled=true

[Rajveer-code]

This looks like a backend artifact rather than something still present in your repo.

When a workflow file is pushed (even briefly), GitHub registers it internally with a workflow ID. If that file is malformed, it can still get indexed, and deleting the file later doesn’t always fully remove the workflow entry from the Actions system.

In your case:

The workflow (BuildFailed, ID: 240241003) is already in "state": "deleted
But Actions is still attempting to evaluate it on each push → resulting in startup_failure

So this isn’t something you can fix from the repo side anymore.

What you can try (just to rule things out)
Disable and re-enable Actions
Settings → Actions → Disable
Then re-enable
This sometimes forces a re-sync of workflows
Rename default branch temporarily
e.g. main → main-temp → main
This can sometimes clear stale workflow references
Force a clean workflow re-index
Add a valid dummy workflow in .github/workflows/
Push → then delete it
(occasionally refreshes the internal registry)
Reality check

If the workflow still shows via API with "state": "deleted" and continues to trigger runs, then this is almost certainly:

a stuck workflow record in GitHub’s backend

At that point, only GitHub staff can remove it.

Recommendation

You’ve already done the right debugging (API check, file removal, etc.), so this is a solid case for support escalation.

When contacting support, include:

Workflow ID: 240241003
Repo: ecucondorSA/Autamedica
Description: persistent startup_failure from deleted workflow
TL;DR
The workflow is deleted in the repo, but still exists internally
That’s why every push triggers a failure
No reliable repo-side fix — needs backend cleanup by GitHub

This is a rare edge case, but you’ve diagnosed it correctly 👍

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[romirr]

Second confirmed case of this exact bug, on a private repository — ghost workflow with the same path: "BuildFailed", state: "deleted" signature, generating a startup_failure on every push/PR event and blocking all valid workflows from running.

For anyone landing here, everything suggested in this thread has been tested and verified failed: deleting ALL runs of the ghost id (the registration 404s, then re-materializes on the next event — reproduced twice, including purging while Actions was disabled with a 10-minute cool-down before re-enabling) · Actions disable/re-enable · re-adding the originally deleted file (gets a new id, ghost persists) · re-claiming the path with a valid .github/workflows/BuildFailed.yml under a different internal name (registers fine as active — ghost still fires) · the full register → disable-via-API → delete lifecycle · default-branch rename round-trip · repository rename round-trip. Removing ALL workflow files stops the failures entirely; adding any single trivial valid workflow brings them back — so file content is ruled out.

@ecucondorSA did GitHub Support ever resolve this for you? I have filed a support ticket requesting a backend purge of the orphaned registration and will report back here if/when it gets fixed.

[lazerusrm]

Confirmed on a second private repository: lazerusrm/NeuralMatrix.

Ghost workflow

• workflow_id: 348088630
• name: ""
• path: BuildFailed
• state: deleted
• html_url: https://github.com/lazerusrm/NeuralMatrix/blob/main/BuildFailed
• created: 2026-09-02T04:09:27Z (first run was pull_request on codex/consumer-remediation-wave22-continuous-20260901 / e3e03c8594bd, dashboard-only, no workflow file change)

Effect
Every push, pull_request, pull_request_target, and schedule event creates a startup_failure run with 0 jobs / 0 check runs attached to that deleted id. Required workflows (Guardrails, Secret scan, Apex) never start. Example: https://github.com/lazerusrm/NeuralMatrix/actions/runs/33631298566

Last real jobs on main were 2026-09-02T03:52:11Z (18009b83, CI Guardrails run 33588658746 — jobs actually executed). YAML on origin/main still parses. GitHub Status was clean.

What did not fix it

1. Disable leftover workflow registrations whose files are gone from main (54 disabled).
2. Disable Actions at repo level, delete all 533 runs of 348088630 (registration then 404s), wait 7 minutes, re-enable allowed_actions=all. The ghost rematerializes on the next event.
3. workflow_dispatch of real files is routed to the correct workflow_id / path, but those runs also startup_failure with 0 jobs (Guardrails 33630653550, smoke 33630839291).
4. Isolated branch whose only workflow was a 16-line ubuntu-latest hello-world still created BuildFailed / 348088630.
5. Landed a valid workflow file at the exact path BuildFailed on main (workflow_dispatch only). The registration stayed state: deleted with empty name; the merge push still went to the phantom. File was removed.

There is no REST/GraphQL API to delete a workflow registration. Please purge orphaned workflow 348088630 for lazerusrm/NeuralMatrix and re-index the repository Actions registry.

Related: https://github.com/orgs/community/discussions/200691 https://github.com/orgs/community/discussions/203806