Examples

Classified CI failures

These are static examples of how Faultline classifies real failure patterns. Each example includes the failure class, confidence score, matched evidence, and suggested remediation.

npm lockfile drift
dependency.lockfile_drift confidence: 0.91
faultline analyze ci-build-4821.log 
failure_id:    dependency.lockfile_drift
confidence:    0.91
evidence:
  - npm ci failed because the lockfile was out of sync
  - package.json and package-lock.json changed inconsistently
suggested_fix:
  - regenerate the lockfile with npm install
  - commit package.json and package-lock.json together
  - add a guard to detect lockfile drift before CI

Evidence

  • npm ci failed because the lockfile was out of sync
  • package.json and package-lock.json changed inconsistently

Suggested fix

  • Regenerate the lockfile with npm install
  • Commit package.json and package-lock.json together
  • Add a pre-commit hook or CI check to catch drift early

Why it happens

Developers update dependencies locally but commit only one of the two dependency files. The lockfile no longer reflects what package.json declares, and npm ci enforces strict lockfile consistency.

Team-level signal This class is worth tracking because it often recurs across PRs without creating new information. If it appears more than twice in a week across multiple contributors, the root cause is usually a missing commit convention or absent pre-commit check — not individual mistakes.
GitHub Actions token permission issue
auth.token_permission_denied confidence: 0.88
faultline analyze ci-build-5102.log 
failure_id:    auth.token_permission_denied
confidence:    0.88
evidence:
  - Error: Resource not accessible by integration
  - GITHUB_TOKEN missing write permission for pull-requests
suggested_fix:
  - add permissions block to the workflow job
  - set pull-requests: write under permissions
  - verify the token scope matches the API call being made

Evidence

  • Error: Resource not accessible by integration
  • GITHUB_TOKEN missing write permission for pull-requests

Suggested fix

  • Add an explicit permissions block to the workflow job
  • Set pull-requests: write under permissions
  • Verify the token scope matches the API call being made

Why it happens

GitHub Actions workflows default to read-only token permissions in many repository configurations. When a step tries to post a comment, create a check, or update a pull request, it fails unless the workflow explicitly declares the required write permissions.

Team-level signal This failure class typically appears in bursts: a workflow author adds a new step that requires write access without knowing the default permission scope. If it recurs across multiple workflows, the fix is a shared workflow template with the correct permissions block applied by default — not repeated per-workflow fixes.
Missing binary / runtime mismatch
env.binary_not_found confidence: 0.94
faultline analyze ci-build-5389.log 
failure_id:    env.binary_not_found
confidence:    0.94
evidence:
  - bash: node: command not found
  - runner image does not include Node.js 22
  - workflow uses ubuntu-latest but requires specific runtime
suggested_fix:
  - pin the runner image to a version with the required runtime
  - add a setup-node step before runtime-dependent steps
  - declare runtime version in .tool-versions or .nvmrc

Evidence

  • bash: node: command not found
  • Runner image does not include Node.js 22
  • Workflow uses ubuntu-latest but requires a specific runtime version

Suggested fix

  • Pin the runner image to a version that includes the required runtime
  • Add a setup-node step before runtime-dependent steps
  • Declare the runtime version in .tool-versions or .nvmrc

Why it happens

Runner images update on a rolling basis and preinstalled runtimes change without notice. Workflows that rely on implicit availability of a binary will silently break when an image update removes or upgrades the version. Using ubuntu-latest without explicitly installing the required runtime is the most common trigger.

Team-level signal Binary-not-found failures are easy to miss because they look like configuration errors rather than repeating patterns. Tracking this class across repos reveals whether teams are relying on implicit runner tooling rather than explicit setup steps. A recurring pattern here usually means a gap in the shared workflow template or missing runtime declarations.

Run it against your own failures.

Install the CLI and point it at any failed build log. No account required.

Try the CLI Read the docs