CI Failure Briefs

Search asset

GitHub Actions failure explainer

When a workflow fails, the fastest useful output is not a perfect root cause. It is a short brief that names the likely failure category, the exact signal, and the next checks.

Try the CI log analyzer
example brief

Likely category

Dependency install failure

Check lockfile drift, package manager version, and cached dependency state before rerunning.

How to read a failed workflow log

  1. Find the first real error line, not only the final exit code.
  2. Look one step above the error for the command that ran.
  3. Classify the failure as install, test, build, lint, permissions, Docker, timeout, or unknown.
  4. Write the next local reproduction command before changing code.
  5. Leave a PR or issue comment that names the signal and the next owner.

Common GitHub Actions failure categories

Signal Likely category First check
npm ERR!, lockfile mismatch Dependency install Re-run the install command locally with the same package manager version.
FAIL, assertion text, test runner output Test failure Run the failing test file or case locally before changing broader code.
tsc, TS2322, build script failure Build or typecheck Run the build command locally and inspect the first compiler error.
permission denied, 401, missing token Secret or permission Check repo secrets, token scope, branch permissions, and environment protection.
Timeout, cancelled, no output Timeout or hanging process Inspect the slowest step and confirm the process exits in CI mode.

Copyable fix brief template

Likely CI failure:
Signal:
Suspected cause:
Next checks:
1. Reproduce locally with:
2. Inspect:
3. Patch:
PR or issue update:
Request early access