How to Rerun Failed GitHub Actions Jobs

To rerun only the failed jobs in a GitHub Actions workflow, open the failed run and choose Re-run jobs → Re-run failed jobs. With GitHub CLI, run gh run rerun RUN_ID --failed. You can also rerun failures through GitHub’s REST API. Reruns are available for 30 days after the original run, are limited to 50 per run, and use the original run’s actor privileges, commit SHA, and ref.

1. Check the failed run before retrying

A rerun repeats work; it does not explain the failure. First identify the failing job and step so you can tell whether a retry is likely to help. GitHub’s run page provides the job summary and logs. The CLI can show the run and retrieve a job’s log.

Open the repository’s Actions tab.
Select the workflow and open the failed run.
Inspect the failed job, step, and log output. Look for an application error, a test assertion, a missing secret, a dependency download problem, or a runner issue.
Decide whether to retry the failed work or first fix the workflow or code. A persistent configuration or code error will usually fail again.

# Show a workflow run
 gh run view RUN_ID

# Show a particular job's full log
 gh run view --job JOB_ID --log

Replace RUN_ID and JOB_ID with the numeric IDs for the run and job. GitHub documents run and log inspection in its workflow run history guide and workflow log guide.

2. Rerun failed jobs in GitHub’s web interface

In the repository, select Actions.
Choose the workflow, then open the failed run.
Select Re-run jobs, then Re-run failed jobs.
If you need additional runner and step diagnostics, enable Enable debug logging.
Select Re-run jobs to start the rerun.

This option reruns the failed jobs and the work GitHub needs to run with them. It leaves already successful, unrelated jobs alone. For a single job, use the job-specific rerun action when available; see section 4.

3. Rerun failed jobs with GitHub CLI

Install and authenticate GitHub CLI (gh) for the repository, then pass the run ID and the --failed flag:

gh run rerun RUN_ID --failed

To request debug logging for the rerun:

gh run rerun RUN_ID --failed --debug

If you omit RUN_ID, GitHub CLI offers an interactive menu for a recent failed run:

gh run rerun --failed

Check the run and job logs first with gh run view as shown above. See the official GitHub CLI rerun command reference for command options.

4. Choose the right rerun scope

What you want to rerun	Use	What to expect
Only failed jobs	Web: Re-run jobs → Re-run failed jobs; CLI: `gh run rerun RUN_ID --failed`	GitHub also reruns dependent jobs as needed.
One particular job	Use the job’s rerun action in the run view, or the REST API endpoint for rerunning a job	Useful when one job needs another attempt. Confirm its dependencies and outputs are appropriate for a retry.
The full workflow	Web: Re-run jobs → Re-run all jobs; CLI: `gh run rerun RUN_ID`	All jobs run again, including ones that previously succeeded.

Rerunning a job does not create a new workflow run from the current branch state. GitHub uses the original run’s GITHUB_SHA and GITHUB_REF. If a fix has been pushed, start a new run for that commit instead of expecting a rerun to pick it up.

5. Rerun jobs through the REST API

For automation, GitHub’s REST API provides endpoints to rerun a workflow run, rerun failed jobs, or rerun an individual job. Fine-grained tokens need Actions repository write permission. The failed-jobs endpoint reruns failed jobs and their dependent jobs.

Example using cURL to rerun failed jobs for a workflow run:

export GH_TOKEN="YOUR_TOKEN"
export OWNER="YOUR_OWNER"
export REPO="YOUR_REPOSITORY"
export RUN_ID="123456789"

curl --fail-with-body -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GH_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/repos/$OWNER/$REPO/actions/runs/$RUN_ID/rerun-failed-jobs"

A successful rerun request returns an accepted response. Handle non-success status codes in scripts, and avoid printing the token in logs. For other scopes and the current parameter details, use GitHub’s workflow runs REST API reference.

6. Limits and behavior to know

30-day window: runs and jobs can be rerun up to 30 days after the initial execution.
50-rerun maximum: a workflow run can be rerun at most 50 times total. Complete reruns and subset reruns both count.
Original permissions: the rerun uses the privileges of the actor who triggered the original run, not the person requesting the rerun.
Original revision: the rerun uses the original GITHUB_SHA and GITHUB_REF.
Dependent work: rerunning failed jobs can include dependent jobs, so inspect the workflow’s dependency graph if more jobs run than expected.

These are GitHub’s documented limits and rerun semantics. The GitHub rerun guide describes the UI procedure, time window, count limit, and original run context.

7. Common problems and fixes

Problem	Likely cause	What to do
The rerun option is missing or unavailable	The run is outside the 30-day rerun window, or the run has reached its 50-rerun limit.	Check the run date and retry history. Push or dispatch a new run if you need to run the workflow again.
The rerun still uses old code	A rerun repeats the original SHA and ref.	Start a new workflow run on the commit containing the fix.
The rerun cannot access a secret or resource	The rerun uses the original triggering actor’s privileges.	Check that actor’s access and the repository or organization secret configuration. If access must change, trigger a new run with the intended context.
`gh` reports that authentication or access failed	The CLI is not authenticated for the repository, or the account lacks permission to rerun the run.	Authenticate with GitHub CLI and verify repository access. For API automation, grant the token Actions write permission.
The REST API returns an authorization error	The token lacks Actions repository write permission, or it is scoped to a different repository.	Grant the required repository permission and check owner, repository, and run ID.
The rerun request returns not found	The owner, repository, run ID, or endpoint is incorrect, or the token cannot see the resource.	Verify the repository path and run ID, then confirm token access.
The same step fails again	The issue is reproducible, such as a test failure, invalid configuration, or missing dependency.	Use the failed-step logs to fix the underlying problem, then start a new run if the commit changes.

8. Reliability, performance, and cost considerations

A rerun is most useful for transient failures, such as a temporary service or runner interruption. Repeatedly retrying deterministic failures adds queue time and consumes workflow resources without fixing the cause. Inspect the failing step, use debug logging when the ordinary log is insufficient, and rerun only the necessary scope.

GitHub Actions usage and billing depend on the repository’s plan, runner type, and minutes consumed; this guide does not assume a particular rate. Check the repository’s usage and billing settings before automating frequent or broad reruns. Set sensible retry limits in automation, record the run ID and outcome, and stop after a bounded number of attempts to avoid exhausting the 50-rerun allowance.

9. Or skip the browser setup

If your workflow also needs screenshots of pages for visual checks or bug reports, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot or PDF, and its parameters support full-page shots, selected elements, custom viewport and device settings, waits, headers, cookies, and more. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Cookie banners are accepted and removed before capture, along with known consent platforms, newsletter popups, and chat widgets. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. An MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

10. Frequently asked questions

Can I rerun a failed job after fixing the code?

A rerun uses the original commit. To test a code fix on a newer commit, start a new workflow run for that commit.

Does rerunning failed jobs rerun dependent jobs too?

Yes. GitHub’s failed-jobs rerun includes dependent jobs that need to run with the failed jobs.

Can I rerun a workflow more than 50 times?

No. The 50-rerun limit applies to the run in total, including full and subset reruns. Start a new run when the limit is reached.

Do I need to be the person who started the run?

The rerun executes with the original triggering actor’s privileges. Your ability to request the rerun and the permissions used by that run are separate considerations.