Re-running and Cancelling Workflow Runs

Not every failed run needs a new commit. A flaky network blip or an occasional slow health check is often worth just running again as-is. And not every run needs to finish — pushing a fix thirty seconds after a run started is a good reason to stop the first one rather than let both finish. This chapter covers both, through the GitHub UI and the gh CLI, using whichever workflow you have handy — nothing here depends on the deploy pipeline specifically.

Re-running From The GitHub UI

Open any run’s page in the Actions tab. Re-run jobs expands into three options:

Re-run all jobs — starts the entire run over, including jobs that already passed.
Re-run failed jobs — only re-runs jobs that didn’t succeed, plus anything that depends on them.
Re-run jobs with debug logging — the option from the earlier chapter on step debug logging.

For a multi-job workflow where only one job failed, Re-run failed jobs is almost always the right call — it saves the time and minutes of redoing work that already succeeded.

Re-running From The `gh` CLI

# Rerun an entire run
gh run rerun <run-id>

# Rerun only the jobs that failed
gh run rerun <run-id> --failed

# Rerun with debug logging forced on
gh run rerun <run-id> --debug

# Rerun a single specific job from the run
gh run rerun <run-id> --job <job-id>

Find a run ID with:

gh run list --workflow=deploy-app.yml --limit 5

Note

--job wants a numeric database ID, not the job number you’d see in a browser URL — those aren’t the same thing, and passing the URL-style number returns a 404. Get the right ID with:

gh run view <run-id> --json jobs --jq '.jobs[] | {name, databaseId}'

then pass the databaseId value to --job.

Cancelling A Run

From the UI, open the running (not yet finished) run and use Cancel workflow. From the CLI:

gh run cancel <run-id>

A cancelled job doesn’t necessarily stop instantly — GitHub Actions sends a cancellation signal, and the runner gives the currently-executing step a grace period to shut down before force-killing it.

Watching A Run In Real Time

gh run watch <run-id>

Streams the run’s progress in your terminal and exits once it finishes. Combine it with a fresh trigger:

gh workflow run deploy-app.yml
gh run watch $(gh run list --workflow=deploy-app.yml --limit 1 --json databaseId --jq '.[0].databaseId')

When To Re-run vs. When To Re-investigate

Re-running is the right move for anything you’re confident is transient — a network blip, an occasional flaky test. It’s the wrong move as a substitute for diagnosis: if a run fails for a reason rooted in your code or configuration (like the renamed env var from the earlier debugging chapter), re-running will just fail the same way again. The failure-pattern table from the previous chapter is a good gut check — if the failure looks like “a late step failed generically because something upstream is actually broken,” re-running won’t help until the upstream thing is fixed.

Last updated on September 20, 2026

Common Failure Patterns Concurrency Control