← Back to the blog

GitHub Actions Logs: Read Them and Re-run Only the Failed Job

By Squidly Team · · 4 min read

  • #github-actions
  • #ci-cd
  • #debugging

To re-run failed jobs in a GitHub Actions workflow run, open the run, click Re-run jobs, and choose Re-run failed jobs. GitHub re-runs the jobs that failed, plus their dependent jobs, without repeating unrelated successful jobs. If several jobs failed and you only want one, use the re-run icon next to that specific job instead. Read the failed job's logs before you re-run, so you know whether the problem is in the code, in the environment, or in a flaky external service.

Read the logs before you re-run

Re-running without reading the logs often wastes a run. Start with the failed step:

  1. Open the workflow run and click the failed job.
  2. Expand the first red step. The first error is usually the real cause; later errors often follow from it.
  3. Use Download log archive or the search box in the log view when the output is long. Search only covers expanded steps.

With the GitHub CLI, you can print only the failed steps of a run:

gh run view <run-id> --log-failed

If the failure looks like a flaky network call, a rate limit or a runner problem, a re-run is reasonable. If the failure comes from a test, a missing secret or a changed dependency, fix the cause first. Code changes require a new commit; a corrected secret or external service may allow the original commit to pass.

Choosing the right action

GitHub offers several actions that people often mix up. They serve different purposes:

Action What it does When to use it
Read the logs Shows what failed, without starting a new run Always, as the first step
Re-run failed jobs Runs again only the failed jobs and their dependents The failure looks transient, or an external cause has been fixed
Re-run a specific job Runs that job and its dependents Only one job needs another attempt
Re-run all jobs Runs the whole workflow again You need to verify the whole workflow on the original commit
Enable debug logging Adds runner and step diagnostics to a re-run The log is not enough to explain the failure

Re-running uses the same commit and Git ref as the original run. If you need to test a code fix, push a new commit instead of re-running the old one.

The same actions are available from the command line:

# Re-run only the failed jobs of a run
gh run rerun <run-id> --failed

# Re-run every job of a run
gh run rerun <run-id>

# Add runner and step debug logs to a failed-jobs re-run
gh run rerun <run-id> --failed --debug

For just one job, get its database ID first, then pass it to --job. Use databaseId from the CLI output, not the number copied from a job's browser URL:

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

In the web interface, select Enable debug logging in the re-run dialog, then confirm with Re-run jobs.

Log retention and re-run permissions affect which actions are available. GitHub allows re-runs up to 30 days after the initial run, with a maximum of 50 re-runs, and the workflow must be enabled. Check these limits and your access if an option is missing.

Re-running one run is simple. Several repositories are not.

A single repository with one workflow is easy to manage. The work changes when the same pipeline spans several repositories, for example a shared library, an API and a front end that all deploy together:

  • You have to open each repository's Actions tab to find the failed run.
  • Each repository keeps its own logs, retention and re-run history.
  • You have to remember which run of which repository belongs to the same release.

Native GitHub tools work well inside one repository. Across several repositories, the question shifts from "how do I re-run this job?" to "which failed job should I look at first, and what else depends on it?"

How Squidly helps with a failed run

Squidly brings the workflow runs from your connected repositories into one view. Premium accounts can re-run a workflow run from its interface:

  1. Find the failed run in the workflow list.
  2. Open that run's actions menu.
  3. Select Re-run workflow.

This acts on one workflow run, not several repositories at once. Do not confuse this run-level control with GitHub's specific-job or failed-jobs-only options described above.

Use it after you have read the logs and confirmed that the failure is transient or its external cause has been fixed. Keep the same rule as before: a re-run does not change the code, so check the cause first.

Summary

  • Read the logs first, then decide whether a re-run makes sense.
  • Use Re-run failed jobs to avoid repeating unrelated successful jobs, or re-run a specific job when that is all you need.
  • Use gh run rerun <run-id> --failed when you prefer the command line.
  • Push a new commit when the code has to change.
  • Once the same pipeline spans several repositories, a single-run approach stops being enough.

For more on the logs themselves, see how to debug a failing GitHub Actions workflow. For following several repositories at once, read how to monitor GitHub Actions across multiple repositories. To compare GitHub's native tools with a dedicated tool, see GitHub Actions: native or Squidly. For notifications when a run fails, see GitHub Actions workflow notifications.

References