`pm2 logs` Is Still the Fastest Way to See Why a Node Process Keeps Looking Fine Until It Doesn’t

Why this command matters: process managers are very good at making chaos look tidy from far away.

PM2 can tell you a process exists. It can even tell you it is online. That does not mean the app is healthy, stable, or doing what you think. A Node service can start, log warnings, throw runtime errors, reconnect forever, restart repeatedly, or limp through startup while PM2 still presents something that looks reassuring enough to waste your time.

That is why pm2 logs is still one of the best first commands when a PM2-managed service behaves strangely.

Start with the logs

pm2 logs

Or for one process:

pm2 logs my-app

This shows stdout and stderr, which often reveal the exact class of problem you need:

1. missing environment variables
2. port conflicts
3. database connection failures
4. uncaught exceptions
5. syntax or startup errors after deployment

That is much more useful than staring at a green "online" indicator and wondering why requests still fail.

Pair it with status and describe

A practical triage loop is:

pm2 status
pm2 logs my-app
pm2 describe my-app

Together these answer:

1. is the process up right now
2. what is it printing while up or during restarts
3. how often has it restarted
4. what script, cwd, env, and uptime does PM2 think apply

That combination is often enough to separate application bugs from process-manager configuration bugs.

What pm2 logs catches faster than dashboards

Developers often over-trust dashboard summaries. They see "1 app online" and move on. But logs may show:

1. the app boots and crashes every 20 seconds
2. a required env var is missing in PM2 but present in your shell
3. a migration is blocking startup
4. the app can bind locally but cannot reach its database

A dashboard compresses. Logs explain.

One useful habit

When debugging a flaky deploy, tail the logs while you trigger real traffic:

pm2 logs my-app

Then hit the endpoint from another terminal:

curl -i http://localhost:3000/health

Now you can correlate the request with the app's actual output instead of guessing from infrastructure symptoms alone.

Common mistake

The most common mistake is reading only historical logs after the fact and missing the live behavior during the failing request path. The second most common mistake is trusting the shell environment instead of the PM2-managed environment. pm2 describe helps there because it shows what PM2 is really running with.

Final recommendation

If a PM2-managed Node service feels unstable, misleading, or just mysteriously "fine," start with pm2 logs and pair it with pm2 status and pm2 describe. The fastest route to the fix is often the error stream the dashboard keeps politely minimizing.

Sources

• PM2 documentation