How to Choose Job-Level vs Test-Level Retry in CI

Retry the whole job when the runner or environment flaked, and retry a single test when the test itself is flaky; matching the level to the cause avoids wasted minutes.

Job-level retry (rerunning the job) is right for infrastructure flakes: network blips, runner loss, a service that was not ready. Test-level retry is right when one test is timing-sensitive. Blanket job retries are expensive and mask which test is at fault.

When to use which

Symptom	Retry level	Why
Runner lost, network timeout	Job	Environment flaked, not the test
One test times out intermittently	Test	Cheaper, isolates the culprit
Whole suite fails to start	Job	Setup or dependency issue
Assertion fails randomly	Fix it	Retry hides a real bug

Job-level retry

.github/workflows/ci.yml

steps:
  - uses: nick-fields/retry@v3
    with:
      max_attempts: 2
      timeout_minutes: 20
      command: npm test

Gotchas

A job retry reruns every test, so it is far more expensive than retrying one test.
Job retries hide which test flaked; use test-level retry when you can pinpoint it.

Related guides

How to Retry Only on Infrastructure Errors in CIRetry only on infrastructure errors in CI by matching transient error types, so network and timeout failures… How to Rerun Only the Failed Tests in CIRerun only the failed tests in CI with pytest --lf, jest onlyFailures, or Go by name, so a second attempt con… How to Avoid the Cost of Blind Retries in CIAvoid the cost of blind retries in CI, where retrying every failure masks real bugs and burns minutes, by tra…