Node.js logging in production: pino vs winston, and what most guides miss

Which library to pick, how to set it up in five minutes, where your logs actually end up, how to follow one request end to end, and how to find out when something stops logging. With code you can copy.

1. The short answer: pino or winston

For a new project, pino. It writes JSON from the start, it's among the fastest, and today it's the most downloaded. If you already have winston and it works, keep it: configure it to write JSON with each error's stack trace and you're done.

Downloads from api.npmjs.org, week of October 5–11, 2026; versions from the npm registry, same day. Many guides still say winston is downloaded more: that's no longer true.

What about morgan? It doesn't compete with either: it only writes one line per HTTP request. If you use pino, pino-http does the same in the same format as the rest of your logs.

2. What about console.log?

In production, console.log has three problems: no levels (you can't turn off debug output without touching code), free-form text (hard to search), and no way to tell which request each line came from.

But if your app is already full of console.log, you don't have to rewrite it to get started. What matters is that those lines end up somewhere searchable. Write the new ones with pino.

3. Pino in five minutes

npm install pino
npm install --save-dev pino-pretty

// logger.js
import pino from 'pino';

export const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  // readable in your terminal; plain JSON in production
  transport: process.env.NODE_ENV === 'production' ? undefined : { target: 'pino-pretty' },
  // what must never be written down
  redact: ['req.headers.authorization', '*.password', '*.card'],
});

import { logger } from './logger.js';

logger.info({ order: 'A-1042', amount: 640 }, 'order paid');
logger.warn({ order: 'A-1042' }, 'out of stock, ships tomorrow');

try {
  await ship(order);
} catch (err) {
  logger.error({ err, order: order.id }, 'could not ship');   // with its stack
}

// one logger per module, with its label on every line
const log = logger.child({ module: 'payments' });

Three rules that save you hours later:

• Data goes in the object, not glued into the text. { order: 'A-1042' } can be filtered; «order A-1042 paid» can't.
• The error goes in err. Pino turns it into type, message and stack.
• The message says what happened, in business terms: «order paid», not «ok» or «step 3».

4. If you already use winston

What people forget most: without format.errors({ stack: true }), errors arrive without a stack trace. Same if you wrap them in an object ({ error: err }).

import winston from 'winston';

export const logger = winston.createLogger({
  level: process.env.LOG_LEVEL || 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.errors({ stack: true }),
    winston.format.json(),
  ),
  transports: [new winston.transports.Console()],
});

// the error as the second argument: that's how it keeps its stack
logger.error('could not ship', err);
// and data, through a child logger
logger.child({ order: 'A-1042' }).warn('out of stock');

5. Every Express request, with its id

npm install pino-http

import pinoHttp from 'pino-http';
import { randomUUID } from 'node:crypto';
import { logger } from './logger.js';

app.use(pinoHttp({
  logger,
  // keep the id your load balancer sends; otherwise, a new one
  genReqId: (req) => req.headers['x-request-id'] || randomUUID(),
}));

app.post('/orders/:id/pay', async (req, res) => {
  req.log.info({ order: req.params.id }, 'charging');   // already carries the request id
  // …
});

Each request writes one line when it finishes, with method, route, status code and duration, and everything you write through req.log carries the same id. When a customer says «it failed at 3:12», you search for that id and see everything that happened.

6. The id everywhere, without passing it around

req.log works in the route, but your charge function, three files down, has no req. Instead of passing it hand to hand, keep it in the request's context with AsyncLocalStorage, which ships with Node:

import { AsyncLocalStorage } from 'node:async_hooks';

const context = new AsyncLocalStorage();

// after pinoHttp
app.use((req, res, next) => context.run(req.log, next));

// anywhere in your code
export const log = () => context.getStore() ?? logger;

log().info({ order }, 'charge approved');   // with the id of the request that asked for it

And if the request crosses several services, the standard way to carry the same id from one to the next is the W3C traceparent header.

7. What stays out of your logs

• Passwords, tokens and keys, including in headers: authorization and cookie are the ones that slip through most.
• Card numbers, full or nearly full.
• Personal data you don't need to understand the problem: the customer id is enough, not their email or phone.

With pino, redact removes them before writing (step 3 above). With winston, a custom format that deletes those fields.

8. Where are my logs?

Your app should write to standard output (stdout) and let whatever runs it store them. Where they end up depends on where it runs:

The problem with all of them: they live on one server or for a short time, and nobody is watching. They help you investigate something you already know happened, not find out that it happened.

9. Have something read them for you

The last missing piece, and the one almost no logging guide covers: finding out without opening them. Three things worth watching:

• New errors, grouped: the same error a thousand times is one alert, not a thousand.
• A service that went quiet. If your worker logged every minute and has been silent for an hour, there's no error to search for: it simply stopped working.
• A process that started and never finished. The paid order that never shipped doesn't write a single error line.

With Estiaje, your pino or winston logs arrive with one more line, without changing how you write them:

import { estiajeFromEnv } from '@estiaje/sdk';
const estiaje = estiajeFromEnv({ service: 'store' });

// pino: to your terminal and to Estiaje
const logger = pino(pino.multistream([
  { stream: process.stdout },
  { stream: estiaje.destino() },
]));

// winston: one more transport
logger.add(new winston.transports.Stream({ stream: estiaje.destino() }));

// still on console.log? those arrive too
estiaje.capturarConsola();

You search them by text and filter by service, level or any field. Errors arrive grouped with their stack, a service that goes quiet alerts your phone, and if you tell it which process must finish, it also alerts you about the one stuck halfway, with the money at risk. Logs are included from the Free plan.

Frequently asked questions

Downloads from api.npmjs.org and versions from the npm registry, checked October 12, 2026.