Beyond console.log — professional debugging techniques for Node.js: using the built-in inspector, debugging in VS Code, reading stack traces, and finding memory leaks.
In this guide
Start your app with the --inspect flag: node --inspect server.js (or node --inspect-brk to pause before the first line). Open Chrome and navigate to chrome://inspect. Click "Open dedicated DevTools for Node." You get the full Chrome DevTools experience: breakpoints, call stack, variable inspection, and the console. This is far more powerful than console.log and requires zero configuration.
Create .vscode/launch.json: { "version": "0.2.0", "configurations": [{ "type": "node", "request": "launch", "name": "Debug App", "program": "${workspaceFolder}/src/server.ts", "runtimeArgs": ["-r", "ts-node/register"], "env": { "NODE_ENV": "development" } }] }. Press F5 to start debugging. Set breakpoints by clicking the line number gutter. Use the Debug Console to evaluate expressions at the current breakpoint. VS Code debugger handles TypeScript, source maps, and environment variables automatically.
A stack trace reads bottom-up: the bottom is where execution started, the top is where the error was thrown. The first line of your own code (not node_modules) in the trace is usually the most important — it is where the error propagated from your application logic. Error message + the first line of your code in the stack is usually enough to find the problem. Use source maps (ts-node, Next.js) to get TypeScript line numbers instead of compiled JavaScript line numbers.
If your Node.js process grows in memory over time without releasing it, you have a memory leak. Common causes: event listeners not removed, closures holding references, global variables accumulating data. Start your app with: node --expose-gc --inspect server.js. In Chrome DevTools → Memory tab, take heap snapshots before and after a suspicious action. The "Comparison" view shows what was allocated and not collected. Look for growing counts of objects of the same type.
console.log in production is hard to query and lacks context. Use a structured logging library: npm install pino. Log: logger.info({ userId: 123, action: "booking_created", bookingId: 456 }, "Booking created"). Output is JSON that can be shipped to a log aggregator (Loki, CloudWatch, Datadog). In production, you can query: find all requests where userId=123 AND status=500 in the last hour. This is impossible with plain text logs.
Need Help?
Our engineering team handles implementations like this every week. Get a free scoping call — we will tell you exactly what it takes and what it costs.
Book a free callCompetitive Intelligence
Efficiency Modeling
© 2026 NexWorldTech — Built for Global Dominance.