0x55aa
← Back to Blog

🔍 Stop console.log Debugging Your Node.js App (The Inspector Is Free)

•5 min read
"nodejs""debugging""backend""express""developer-tools"

🔍 Stop console.log Debugging Your Node.js App (The Inspector Is Free)

Picture this: your Express API is returning wrong data. You don't know why. So you do what every developer has done since the dawn of JavaScript:

console.log('HERE 1');
console.log('req.body', req.body);
console.log('result????', result);
console.log('WHY IS THIS WRONG', JSON.stringify(thing, null, 2));

You commit this. You push it. Your teammate sees it in code review and questions every life choice you've ever made.

There's a better way. Node.js has shipped a full Chrome DevTools inspector since v6. You probably never opened it. Let's fix that.

The --inspect Flag You've Been Ignoring

Start any Node.js process with one extra flag:

node --inspect server.js
# or for watch mode
node --inspect --watch server.js
# or with nodemon
nodemon --inspect server.js

You'll see this:

Debugger listening on ws://127.0.0.1:9229/some-uuid
For help, see: https://nodejs.org/en/docs/inspector

Now open Chrome (yes, regular Chrome) and navigate to:

chrome://inspect

Click "Open dedicated DevTools for Node" and boom — you have a full debugger. Set breakpoints. Inspect variables. Step through code. Watch expressions update in real time.

No more console.log. No more JSON.stringify sprawl. Just actual debugging, like it's 2024 (or 2026, we're not judging).

The debugger Statement: Your New Best Friend

Here's the thing nobody tells you: you can put a debugger statement directly in your code, and when the inspector is attached, execution will pause right there.

app.post('/orders', async (req, res) => {
  const { userId, items } = req.body;

  debugger; // 👈 execution pauses HERE when inspector is attached

  const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
  const order = await Order.create({ userId, items, total });

  res.json(order);
});

When your app hits that line with the inspector open, Chrome freezes execution and shows you the exact state of every variable in scope. You can hover over items, expand it, see every property, then press F8 to continue.

It's like console.log but you can actually look around instead of guessing what to log.

Remove debugger statements before committing. Unlike console.logs, they're at least harmless when the inspector isn't attached — but your team will still give you the look.

Profiling: Find the Slow Part Without Guessing

Debugging is for correctness. Profiling is for performance. And the same inspector tab does both.

node --inspect server.js

In Chrome DevTools, go to the Profiler tab and hit Start. Hit your slow endpoint a few times. Hit Stop. Chrome shows you a flame graph of every function call and exactly how long each one took.

Here's a contrived example of what you might catch:

// This looks innocent but kills you at scale
app.get('/products', async (req, res) => {
  const products = await db.query('SELECT * FROM products');

  // 🔥 You're calling an async function inside a map — it's not awaited properly
  const enriched = products.map(async (p) => {
    const reviews = await db.query('SELECT * FROM reviews WHERE product_id = ?', [p.id]);
    return { ...p, reviews };
  });

  // enriched is an array of Promises, not resolved values 😬
  res.json(enriched);
});

With console.log, you'd never see the bug clearly. With the profiler, you'd see the N+1 query pattern immediately — one DB call per product, each showing up as a stack of async calls stacking latency.

The fix:

app.get('/products', async (req, res) => {
  const products = await db.query('SELECT * FROM products');
  const productIds = products.map(p => p.id);

  // One query to get all reviews, not N queries
  const reviews = await db.query(
    'SELECT * FROM reviews WHERE product_id IN (?)',
    [productIds]
  );

  const reviewMap = reviews.reduce((acc, r) => {
    acc[r.product_id] = acc[r.product_id] || [];
    acc[r.product_id].push(r);
    return acc;
  }, {});

  const enriched = products.map(p => ({ ...p, reviews: reviewMap[p.id] || [] }));
  res.json(enriched);
});

The profiler helped you find it. The fix is yours to write.

VS Code Integration (Zero Chrome Required)

If you live in VS Code, you don't even need Chrome. Create a .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Express App",
      "skipFiles": ["<node_internals>/**"],
      "program": "${workspaceFolder}/server.js",
      "env": {
        "NODE_ENV": "development"
      }
    }
  ]
}

Hit F5. Your app starts with the debugger attached. Click the gutter next to any line number to set a breakpoint. When your code hits it, VS Code highlights the line, shows you all local variables in the sidebar, and lets you evaluate expressions in the Debug Console.

It's like magic, except it shipped in 2016 and you've been writing console.log ever since.

Quick Reference

What you want Command
Start with inspector node --inspect server.js
Break on first line node --inspect-brk server.js
Open in Chrome chrome://inspect
Pause in code Add debugger; statement
VS Code debug F5 with launch.json
Profile CPU DevTools → Profiler tab
Heap snapshot DevTools → Memory tab

The Real Talk

console.log isn't evil. It's fast for quick sanity checks. But when you're three hours into debugging a race condition and your terminal looks like a Jackson Pollock painting of JSON blobs, it's time to reach for the real tools.

The Node.js inspector is built-in, free, and has been patiently waiting for you to notice it. Your future self (and your teammates) will thank you.

Set one breakpoint today. Just one. See how it feels.

What's your go-to debugging approach? Are you a console.log loyalist, a VS Code debugger convert, or do you have some third option nobody's heard of? Drop it in the comments — debugging war stories are always welcome.

← Back to all posts