Orphaned deleted workflow (id 310184205, path "BuildFailed") keeps triggering runs — DELETE returns 404, disable returns 403

[DenisSeko]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Hi,

I have a workflow in my repository that is marked as deleted but still triggers runs, and I can't remove or disable it.

Repository: DenisSeko/ServicesPlatform (private)

GET /repos/DenisSeko/ServicesPlatform/actions/workflows/310184205 returns:

{
  "id": 310184205,
  "name": "",
  "path": "BuildFailed",
  "state": "deleted",
  "created_at": "2026-07-09T20:19:32.000+02:00",
  "html_url": "https://github.com/DenisSeko/ServicesPlatform/blob/development/BuildFailed"
}

Observations

• state is deleted, name is empty, and path is BuildFailed — there is no such file in the repository.
• It does not appear in GET /repos/.../actions/workflows nor in gh workflow list --all.
• In the web UI it is displayed as "(Unnamed workflow)".
• It has generated 40 runs, all with conclusion: "startup_failure", triggered by both push and schedule. Latest run: 39274749280 (2026-10-19T15:04:46Z).

What I have tried

DELETE /repos/DenisSeko/ServicesPlatform/actions/workflows/310184205
→ 404 Not Found

PUT /repos/DenisSeko/ServicesPlatform/actions/workflows/310184205/disable
→ 403 "Unable to disable a workflow that is not active."

Disabling and re-enabling Actions for the repository did not help either.

Question

Is there any supported way to remove a workflow that is stuck in this deleted state, or does this require GitHub Support to purge it server-side?

The impact is mostly noise: a red startup_failure entry appears in the Actions tab on a daily schedule, which makes the real CI status hard to read.

Thanks!

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

[RolandJL]

Hi Denis,

This issue is a known GitHub Actions backend database bug where the workflow event-dispatch system keeps listening to push or schedule webhooks even though the actual .yaml file has been deleted, resulting in automated ghost runs that end in a permanent startup_failure status error.

Because the GitHub API blocks any manual fixes by returning 404 or 403 errors when trying to purge or change the state of a deleted file, you must submit a ticket via the GitHub Support Portal so that engineering staff can run an internal server-side database cleanup or force a structural re-index of your repository.

While you are waiting for a support response, a reliable community workaround to clear the UI clutter is to temporarily re-commit a dummy workflow file at the exact historical path (.github/workflows/BuildFailed), wait for the background worker to register the workflow as active again in your repository layout, click the manual Disable button directly within the GitHub Actions Web UI for that specific workflow, and then safely run a git delete to remove the dummy file from your repository once more. This should temporarily hijack the broken webhook and allow you to turn it off manually while the engineering team processes your backend database purge.

Regards,

[DenisSeko]

Thanks for the reply, Roland — much appreciated.

One correction that matters for the workaround: the record's path is BuildFailed at the repository root (its html_url points to blob/development/BuildFailed), not .github/workflows/BuildFailed. Since GitHub only parses workflows from .github/workflows/, a dummy file at the root path would not be registered as a workflow at all. And even at the correct location, a newly committed file would register under a new workflow ID rather than re-attach to 310184205 — the record also has an empty name, which looks like a half-registered row rather than a normal file-backed workflow. In the cases you have seen, did the trick actually reclaim the same workflow ID?

Current state, for reference:

• GET /repos/DenisSeko/ServicesPlatform/actions/workflows/310184205 → state: "deleted", name: "", path: "BuildFailed"
• not listed in GET /actions/workflows, nor in gh workflow list --all; shows as "(Unnamed workflow)" in the UI
• DELETE → 404; PUT .../disable → 403 ("Unable to disable a workflow that is not active")
• 40 runs in total, all startup_failure

One update that may be relevant: the orphan has not produced a single run since 2026-10-19T15:04:46Z (run 39274749280). The run count has been stuck at 40 for three days, while the repo's real scheduled workflows (Code Review, Integrity Check) keep firing normally on 20 and 21 October. So it went quiet at roughly the same time as the Actions/Pages/Webhooks incident that day — whether that is causal or coincidence, I honestly cannot tell yet.

I am filing a support ticket for the server-side purge now, as you suggested. Do you have a link to the known-bug reference or changelog entry you mentioned? I would like to attach it.

Regards,
Denis

[RolandJL]

Hello Denis

You are honderd procent correct, and I completely stand corrected on that workaround. Because your record references a root-level path (BuildFailed) with an empty name string, the dummy file trick will not reclaim the same workflow ID (310184205). The parser ignores root-level files, confirming this is a half-registered backend database row rather than a standard configuration issue.

For your support ticket, you can reference GitHub Community Discussion #190193, #207900, and #206902. They cover this exact database failure condition, showing matching data footprints with a "BuildFailed" path, empty names, and endless startup_failure runs.

The correlation with the October 19th outage is highly likely a replication race condition that locked this row into its corrupted state. When you file the ticket, ask the agent to route it directly to the Actions Infrastructure Team for a hard metadata re-index and an internal record purge.

Regards

Roland

[DenisSeko]

Thanks Roland — and genuinely, thank you for coming back to correct the workaround yourself. Most threads never get that, and it saved me from chasing a dead end.

I checked the three references before replying. They hold up: #190193, #207900 and #206902 are all still open and unanswered, and the two from September describe a BuildFailed path with 0 jobs and an empty name — the same half-registered footprint I'm looking at. Your diagnosis is solid, and those links were exactly what I needed.

One detail worth flagging, because it shifts the framing rather than the conclusion: all three predate the October 19 incident — #190193 goes back to March, the other two to early September. So I'll describe this as a long-standing reconciliation defect for deleted or half-registered workflow rows, rather than as fallout from that outage. My orphan going quiet on the 19th is then more likely coincidence; possibly a side effect of the re-index done during recovery, but I won't claim causality. Same fix either way, just a cleaner story for the ticket.

I'll pass your routing suggestion along and ask specifically for the Actions Infrastructure Team, a hard metadata re-index and an internal record purge, citing those three threads. If support comes back with anything shareable, I'll post it here so the next person hitting this has the trail.

State is unchanged on my side: 40 runs, nothing new since 2026-10-19T15:04:46Z (run 39274749280), state: "deleted", name: "", DELETE → 404, disable → 403. Inert, but still there.

Thanks again — the pointers were the useful part.