Skipped job leaves its workflow run stuck at in_progress; cancel, force-cancel and delete all fail

[jaylenkorth-jdmccormick]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Six workflow runs have been sitting at status: in_progress since August 7–9. Their jobs are finished — the run record just never closed out.

Each run has exactly one job, and that job reports completed / skipped, because the job-level if: evaluated false. The run itself stays in_progress indefinitely:
run 31146705075 in_progress/- job completed/skipped since 2026-08-07T04:12Z
run 31208144696 in_progress/- job completed/skipped since 2026-08-07T18:41Z
run 31257213082 in_progress/- job completed/skipped since 2026-08-08T12:25Z
run 31257343842 in_progress/- job completed/skipped since 2026-08-08T12:29Z
run 31295686247 in_progress/- job completed/skipped since 2026-08-09T04:58Z
run 31308328478 in_progress/- job completed/skipped since 2026-08-09T10:26Z

It is intermittent rather than systematic. The same workflow has ~48 other runs whose single job was also skipped, and every one of those correctly ended as completed / skipped. Only these six failed to transition.
Nothing clears them:

Attempt	Result
POST /repos/{owner}/{repo}/actions/runs/{id}/cancel	HTTP 500 Failed to cancel workflow run
POST /repos/{owner}/{repo}/actions/runs/{id}/force-cancel	HTTP 500 Failed to cancel workflow run
DELETE /repos/{owner}/{repo}/actions/runs/{id}	Could not delete the workflow run
Deletion requires the run to be completed, and completing it requires a cancel that returns 500 — so there is no path out through the API.
The workflow is triggered by workflow_run and gates on the upstream conclusion:

on:
  workflow_run:
    workflows: ["..."]
    types: [completed]
jobs:
  alert:
    if: >-
      github.event_name == 'workflow_dispatch' ||
      github.event.workflow_run.conclusion == 'failure'
These appeared during a window on August 6–7 when several unrelated jobs in the same repository were also cancelled unexpectedly, which makes me think infrastructure rather than workflow definition.

Worth noting for anyone hitting this: timeout-minutes does not help. The job is skipped, so it never starts, and there is nothing for a job timeout to terminate — the stuck state lives in the run record.

Has anyone seen a skipped job leave its run in_progress, and found a way to force it terminal once both cancel endpoints 500? Or do these get swept server-side eventually?

Nothing is broken in practice — no runners are consumed and scheduled jobs are unaffected. It is six entries in the Actions tab that will apparently never finish.

One formatting note: the run-ID block and the YAML block are fenced inside this, so if you're copying the whole thing be careful the outer fence doesn't swallow them — safest is to select from "Six workflow runs" through the final line rather than grabbing the outer code block.
Their template may split this into separate fields (what happened / expected / steps). If so, the first paragraph plus the run table is your "what happened," and the three failed endpoints are your "what I tried."

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

[mhmdwaelanwr]

This looks much more like a stuck workflow-run record on GitHub's side than a workflow configuration problem.

The strongest signals are:

• the only job is already terminal (completed / skipped);
• roughly 48 equivalent skipped runs completed normally;
• only these six remained in_progress;
• both the normal cancel and force-cancel endpoints return HTTP 500.

GitHub documents force-cancel specifically as the fallback when a normal workflow cancellation does not respond. Since even that endpoint fails with a server error, there does not appear to be another user-side API that can force the run record into a terminal state.

One potentially useful detail: GitHub's workflow-run management documentation says a run can be deleted if it is completed or more than two weeks old.

So for these particular runs, I would try the delete endpoint again once each run is older than 14 days. That would not repair the incorrect in_progress state, but it may at least let you remove the orphaned entries from the Actions history.

Until then, I would treat this as a GitHub Actions backend/state reconciliation issue and open a GitHub Support ticket with:

• the six run IDs;
• job IDs and their completed/skipped status;
• timestamps;
• the HTTP 500 responses from both /cancel and /force-cancel;
• an example of one of the ~48 equivalent runs that terminated correctly.

I would not change the job-level if: or add timeout-minutes as a workaround. The condition is behaving correctly — the job is being skipped — and there is no running job for a timeout to terminate.

So the practical answer seems to be: there is no documented client-side way to repair the run state once both cancellation endpoints fail; retry deletion after the 14-day threshold, and report the stuck records to GitHub Support.