Debugging a Node.js Application

console.log() is most people's first debugging tool, and honestly, it stays useful forever for a quick check. But once a bug lives inside a tangle of callbacks or a loop that runs hundreds of times, sprinkling console.log() everywhere becomes noisy and slow. Node.js ships with a proper debugger built in — no extra install needed.

Starting a debug session

node --inspect-brk app.js

--inspect starts the debugger and lets your program run normally; --inspect-brk does the same but pauses execution on the very first line, giving you a chance to set things up before anything runs.

Attaching Chrome DevTools to it

Node.js's inspector protocol is the same one Chrome uses for its own DevTools, so you can debug server-side JavaScript with a familiar browser interface:

1. Run node --inspect-brk app.js in your terminal.
2. Open Chrome and go to chrome://inspect.
3. Under "Remote Target," click inspect next to your running script.
4. A full DevTools window opens — Sources tab, breakpoints, call stack, variable inspection, all working against your actual running Node.js process.

Setting a breakpoint directly in code

You don't have to click line numbers in DevTools — you can also pause execution from inside your own code:

function calculateTotal(items) {
  let total = 0;
  for (const item of items) {
    debugger; // execution pauses here when a debugger is attached
    total += item.price;
  }
  return total;
}

With no debugger attached, the debugger; statement does nothing at all — it's completely safe to leave in during development and simply doesn't run in production unless you're actively debugging.

A quicker option for many day-to-day bugs: Node's built-in CLI debugger

node inspect app.js

This drops you into a text-based debugger right in the terminal, with commands like next (step to the next line), cont (continue until the next breakpoint), and repl (drop into a REPL at the current point in execution to inspect variables). It's less visual than DevTools, but handy when you're already SSH'd into a remote machine with no browser access.

A practical mix that works well

• Reach for console.log() for a fast, one-off check of a value.
• Reach for the debugger (DevTools or CLI) when you need to actually pause execution and walk through logic step by step, inspecting the full state at each point — especially inside loops, recursive functions, or asynchronous chains where print statements alone get confusing fast.