Deploy Error Decoder

'npm ERR! code ELIFECYCLE' — how to find the real error

Quick answer: npm ERR! code ELIFECYCLE is not the real error — it just means the npm script you ran exited with a non-zero code. The actual failure is in the lines above it. Scroll up, find the real error (a failing build, test, or missing binary), and fix that. ELIFECYCLE is only the messenger reporting that a script failed.

What the error looks like

npm reports that a lifecycle script failed, with an errno — but the cause is higher up:

> [email protected] build
> tsc -p .
src/index.ts:10:5 - error TS2322: Type 'string' is not assignable...

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `tsc -p .`
npm ERR! Failed at the [email protected] build script.

The TS2322 line is the real error; ELIFECYCLE errno 1 is npm telling you the build script returned a failure. Fix the line above, and ELIFECYCLE disappears.

Why it happens

The underlying command failed

A compile error, a failing test, or a CLI returning non-zero — that's the real fault.

Node/tool version mismatch

The script needs a Node or dependency version different from what's installed.

A missing dependency or binary

The script calls a tool that isn't installed, so it exits non-zero.

Stale node_modules

A half-installed or out-of-date tree makes a script that should work fail.

Diagnose it in three steps

1

Read above the ELIFECYCLE line

# The real error is printed BEFORE the npm ERR! block.
# Scroll up to the first error/failure message.
2

Run the underlying command directly

# If the script is 'build': "tsc -p .", run that by hand:
npx tsc -p .
# You get the real error without npm's wrapper noise.
3

Reset the toolchain if needed

node -v                      # matches the project's engines?
rm -rf node_modules package-lock.json && npm install
The real fix

Fix the failing command, then make installs reproducible

ELIFECYCLE clears the moment the underlying command succeeds. To stop it recurring across machines and CI, pin the Node version and install from the lockfile:

# package.json — fail fast on the wrong Node
"engines": { "node": ">=20 <21" }
# CI / prod — reproducible install
npm ci
How Infraveil handles this

A broken build, caught at the gate

A failing build script shouldn't reach production. Infraveil verifies a deploy before it runs on your own servers — nothing starts until it passes — so a build that exits non-zero is stopped at the gate, not discovered as a crash in front of users. Releases are approval-gated and recorded, with one-click rollback.

Deploys are verified before they run — a failed build is caught early
One-click rollback to the last release that built and started cleanly
Every deploy recorded in a tamper-evident trail, on servers you control
See how it works More deploy fixes

Frequently asked questions

What does 'npm ERR! code ELIFECYCLE' mean?

An npm lifecycle script (like build or start) exited with a non-zero status. ELIFECYCLE is npm reporting that failure — it is not the underlying error itself.

Where is the real error?

In the output printed above the npm ERR! block — the first error or failure message. ELIFECYCLE just wraps it.

How do I debug ELIFECYCLE?

Run the script's underlying command directly (e.g. npx tsc -p . instead of npm run build) to see the real error without npm's wrapper, then fix that.

Why does it happen only in CI?

Often a Node version or dependency mismatch. Pin engines in package.json and use npm ci for a reproducible install that matches the lockfile.