Logging in Node.js with Winston and Pino

Your production API is returning 500 errors but console.log('something broke') tells you nothing. You need structured logs with timestamps, request IDs, and stack traces — but console.log outputs free-text strings that log aggregators cannot parse or search. Structured logging (JSON output) is the foundation of observability, and choosing between Winston (feature-rich) and Pino (high-performance) depends on your traffic volume and infrastructure. This article covers setting up both libraries, structured log formats, and the production logging patterns that saved teams hours of debugging time.

Why You Need a Logger: The Case Against console.log

In production, console.log is a liability. It lacks log levels, structured output, and performance guarantees. When your Node.js process crashes, you lose all buffered console output. Worse, console.log is synchronous in some environments, blocking the event loop under heavy load. A proper logging library gives you log levels (debug, info, warn, error), structured JSON output for machine parsing, and asynchronous logging to avoid I/O bottlenecks. This article compares Winston and Pino — two industry-standard loggers — so you can choose the right tool for your stack. We'll cover setup, configuration, transports, and real-world failure modes.

// Bad: console.log in production
console.log('User logged in', { userId: 123 });

// Good: structured logging with levels
const logger = require('./logger');
logger.info('User logged in', { userId: 123 });

Winston: The Swiss Army Knife of Logging

Winston is the most popular Node.js logger, known for its flexibility. It supports multiple transports (console, file, HTTP, database), custom formats, and log levels. You can chain transports to send errors to one destination and info logs to another. Winston's format system lets you add timestamps, colorize output, or produce JSON. However, this flexibility comes at a cost: Winston is slower than Pino because it processes logs through a pipeline of transforms. For most applications, the performance difference is negligible, but under extreme load (10k+ logs/sec), Winston can become a bottleneck. Winston is ideal for monoliths or apps where log volume is moderate and you need rich formatting.

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});

logger.info('Server started', { port: 3000 });
logger.error('Database connection failed', { error: err.message });

Pino: Blazing Fast Structured Logging

Pino is designed for speed. It claims to be over 5x faster than Winston by minimizing overhead. Pino achieves this by using a minimal core and offloading formatting to a separate process (pino-pretty) for development. In production, Pino outputs pure JSON with no frills. It also supports child loggers for request-scoped logging, which is essential for tracing. Pino's API is similar to Winston's, but it lacks built-in transports for files or HTTP — you pipe its output to another tool like pino/file or pino-socket. This makes Pino ideal for microservices and serverless where every millisecond counts.

const pino = require('pino');

const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  transport: {
    target: 'pino/file',
    options: { destination: './app.log' }
  }
});

logger.info('Server started', { port: 3000 });
logger.error('Database connection failed', { error: err.message });

// Child logger for request context
const childLogger = logger.child({ requestId: 'abc-123' });
childLogger.info('Handling request');

Setting Up Log Levels and Formatting

Both Winston and Pino support custom log levels and formatting. Winston uses a format pipeline: you combine timestamp, json, printf, etc. Pino uses a simpler approach — you can pass a formatter function or use pino-pretty for development. In production, always output JSON for machine parsing. Set the log level via environment variable (LOG_LEVEL) so you can change it without redeploying. Common levels: error (0), warn (1), info (2), debug (3). Never log sensitive data like passwords or tokens. Use redaction if needed.

// Winston custom levels
const customLevels = {
  levels: { fatal: 0, error: 1, warn: 2, info: 3, debug: 4 },
  colors: { fatal: 'red', error: 'red', warn: 'yellow', info: 'green', debug: 'blue' }
};

const winston = require('winston');
winston.addColors(customLevels.colors);
const logger = winston.createLogger({
  levels: customLevels.levels,
  level: process.env.LOG_LEVEL || 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [new winston.transports.Console()]
});

// Pino custom levels
const pino = require('pino');
const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  customLevels: { fatal: 60, error: 50, warn: 40, info: 30, debug: 20 },
  useOnlyCustomLevels: true
});

Transports: Where Your Logs Go

Transports define where log output is sent. Winston has built-in transports for console, file, HTTP, and more. Pino relies on external transports via its 'transport' option or by piping stdout. For file logging, Winston writes directly; Pino uses pino/file or pino-roll for rotation. For external services (e.g., Elasticsearch, Datadog), Winston has community transports; Pino can pipe to pino-socket or use a custom transport. In production, never log to the same file from multiple processes — use log rotation and consider centralized logging.

// Winston file transport with rotation
const winston = require('winston');
require('winston-daily-rotate-file');

const transport = new winston.transports.DailyRotateFile({
  filename: 'app-%DATE%.log',
  datePattern: 'YYYY-MM-DD',
  maxSize: '20m',
  maxFiles: '14d'
});

const logger = winston.createLogger({
  transports: [transport]
});

// Pino file transport with rotation
const pino = require('pino');
const logger = pino({
  transport: {
    target: 'pino-roll',
    options: {
      file: 'app.log',
      frequency: 'daily',
      size: '20M',
      maxFiles: 14
    }
  }
});

Structured Logging with Context and Correlation IDs

In microservices, you need to correlate logs across services. Use correlation IDs (e.g., request ID) passed via HTTP headers. Both Winston and Pino support child loggers that inherit parent context. Attach the correlation ID to every log entry. This allows you to trace a request through multiple services. Also include useful context like user ID, service name, and environment. Avoid logging large objects — truncate or omit them.

// Express middleware for correlation ID
const { v4: uuidv4 } = require('uuid');

function correlationMiddleware(req, res, next) {
  req.correlationId = req.headers['x-correlation-id'] || uuidv4();
  res.setHeader('x-correlation-id', req.correlationId);
  next();
}

// Winston child logger
app.use((req, res, next) => {
  req.logger = logger.child({ correlationId: req.correlationId });
  next();
});

// Pino child logger
app.use((req, res, next) => {
  req.logger = logger.child({ correlationId: req.correlationId });
  next();
});

// Usage in route
app.get('/api', (req, res) => {
  req.logger.info('Handling request');
  res.json({ ok: true });
});

Performance Benchmarks: Winston vs Pino

Pino is consistently faster than Winston in benchmarks. In a typical scenario (10k logs/sec), Pino processes logs in ~5ms while Winston takes ~30ms. Under load, Winston's overhead can cause event loop delays. However, for most applications (<1k logs/sec), the difference is negligible. Choose Pino if you're building a high-throughput API, serverless function, or real-time system. Choose Winston if you need rich formatting or built-in transports. Always benchmark with your actual log volume and format.

// Simple benchmark (run with node)
const winston = require('winston');
const pino = require('pino');

const wLogger = winston.createLogger({ transports: [new winston.transports.Console()] });
const pLogger = pino({ level: 'info' });

console.time('winston');
for (let i = 0; i < 10000; i++) {
  wLogger.info('test');
}
console.timeEnd('winston');

console.time('pino');
for (let i = 0; i < 10000; i++) {
  pLogger.info('test');
}
console.timeEnd('pino');

Production Best Practices: Log Rotation, Sampling, and Alerting

In production, logs can grow unbounded. Implement log rotation (daily or by size) and retention policies. Use log sampling for high-volume debug logs — log only a percentage of requests. Set up alerting on error logs using tools like Sentry, Datadog, or a simple script that tails error logs. Never log sensitive data; use redaction. Also, consider structured logging with a schema (e.g., ECS) for consistency across services.

// Winston production config
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.errors({ stack: true }),
    winston.format.json()
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'error.log', level: 'error', maxsize: 5242880, maxFiles: 5 })
  ]
});

// Pino production config with redaction
const logger = pino({
  level: 'info',
  redact: ['password', 'secret'],
  transport: {
    target: 'pino/file',
    options: { destination: 1 } // stdout
  }
});

// Log sampling (example)
const sampleRate = 0.1; // 10%
if (Math.random() < sampleRate) {
  logger.debug('Expensive debug log');
}

Migrating from Winston to Pino (or Vice Versa)

Migrating loggers is straightforward if you use a consistent interface. Both libraries support similar APIs: logger.info(), logger.error(), child loggers. The main differences are in configuration and transports. To migrate, create a wrapper that abstracts the logger. This way, you can swap implementations without changing application code. For example, define a logger module that exports info, error, etc., and internally uses Winston or Pino. This also makes testing easier — you can inject a mock logger.

// logger.js — abstraction layer
const pino = require('pino');
const winston = require('winston');

const usePino = process.env.LOGGER === 'pino';

let logger;
if (usePino) {
  logger = pino({ level: process.env.LOG_LEVEL || 'info' });
} else {
  logger = winston.createLogger({
    level: process.env.LOG_LEVEL || 'info',
    transports: [new winston.transports.Console()]
  });
}

module.exports = {
  info: (msg, ctx) => logger.info(ctx, msg),
  error: (msg, ctx) => logger.error(ctx, msg),
  child: (bindings) => logger.child(bindings)
};

Testing Logs: How to Assert Log Output

Testing log output is important to ensure your logging works correctly. Both Winston and Pino support custom transports for testing. For Winston, you can use a custom transport that stores logs in memory. For Pino, you can use pino-test or a custom destination. In unit tests, assert that the correct log level and message were called. Avoid testing log output in integration tests unless necessary — focus on behavior.

// Winston test transport
const { Writable } = require('stream');

class TestTransport extends Writable {
  constructor() {
    super({ objectMode: true });
    this.logs = [];
  }
  _write(chunk, encoding, callback) {
    this.logs.push(chunk);
    callback();
  }
}

// Test
const transport = new TestTransport();
const logger = winston.createLogger({ transports: [transport] });
logger.info('test', { key: 'value' });
assert.strictEqual(transport.logs[0].level, 'info');
assert.strictEqual(transport.logs[0].message, 'test');

// Pino test (using pino-test)
const { test } = require('pino-test');
const logger = pino(test());
logger.info('test');
// pino-test captures output automatically

Centralized Logging: Aggregating Logs from Multiple Services

In a distributed system, you need a centralized logging solution. Common options: ELK stack (Elasticsearch, Logstash, Kibana), Datadog, or AWS CloudWatch. Both Winston and Pino can send logs to these services via transports or by piping stdout. For Winston, use winston-elasticsearch or winston-datadog. For Pino, use pino-elasticsearch or pino-datadog. Alternatively, have your app log to stdout and let the container runtime (e.g., Docker) collect logs. This is the twelve-factor app approach.

// Winston to Elasticsearch
const Elasticsearch = require('winston-elasticsearch');

const esTransport = new Elasticsearch({
  level: 'info',
  clientOpts: { node: 'http://localhost:9200' },
  index: 'app-logs'
});

const logger = winston.createLogger({ transports: [esTransport] });

// Pino to Elasticsearch via pino-elasticsearch
const pino = require('pino');
const logger = pino({
  transport: {
    target: 'pino-elasticsearch',
    options: { node: 'http://localhost:9200', index: 'app-logs' }
  }
});

// Or simply log to stdout and use a log shipper (e.g., Filebeat)
const logger = pino(); // logs to stdout
// Filebeat reads stdout and sends to Elasticsearch

Error Handling: Logging Errors with Stack Traces

When logging errors, always include the full stack trace. Both Winston and Pino support this. Winston's format.errors({ stack: true }) adds the stack to the log entry. Pino automatically includes the stack if you pass an Error object. Never log errors as strings — always pass the Error object. Also, log the error context (e.g., request URL, user ID) to aid debugging.

// Winston error logging
const logger = winston.createLogger({
  format: winston.format.combine(
    winston.format.errors({ stack: true }),
    winston.format.json()
  ),
  transports: [new winston.transports.Console()]
});

try {
  throw new Error('Something went wrong');
} catch (err) {
  logger.error('Operation failed', { error: err, requestId: 'abc' });
}

// Pino error logging
const logger = pino();
try {
  throw new Error('Something went wrong');
} catch (err) {
  logger.error({ err, requestId: 'abc' }, 'Operation failed');
}

AsyncLocalStorage Correlation IDs with mixin()

Correlation IDs are essential for tracing requests across microservices. Node.js AsyncLocalStorage (ALS) provides a clean way to propagate context without passing it manually. Winston and Pino both support a mixin() function that enriches every log entry with context from ALS. In Winston, set mixin in the logger options to read from ALS. For Pino, pass mixin to the constructor. This approach avoids polluting your business logic with logging concerns. Always clean up the ALS store after the request completes (e.g., in middleware). Use a unique ID per request, generated via crypto.randomUUID() or a library like uuid. This pattern works seamlessly with both loggers and is the standard for distributed tracing in Node.js.

const { AsyncLocalStorage } = require('async_hooks');
const crypto = require('crypto');
const pino = require('pino');

const als = new AsyncLocalStorage();

const logger = pino({
  mixin() {
    const store = als.getStore();
    return store ? { correlationId: store.correlationId } : {};
  }
});

// Express middleware
app.use((req, res, next) => {
  const correlationId = req.headers['x-correlation-id'] || crypto.randomUUID();
  als.run({ correlationId }, () => {
    res.setHeader('x-correlation-id', correlationId);
    next();
  });
});

// Usage
app.get('/api', (req, res) => {
  logger.info('Handling request');
  res.json({ ok: true });
});

Pino Custom Serializers for Redaction

Pino serializers transform log object properties before output. They are ideal for redacting sensitive fields like passwords, credit cards, or tokens. Define serializers in the Pino options object, keyed by property name. Each serializer receives the value and must return a safe representation. For nested fields, use dot notation in the key (e.g., 'user.password'). Pino also has a built-in redact option for simple cases, but serializers offer more control. Combine serializers with redact for maximum safety. Always test serializers with actual sensitive data to ensure no leaks. Remember that serializers run on every log, so keep them performant.

const pino = require('pino');

const logger = pino({
  serializers: {
    req: (req) => ({
      method: req.method,
      url: req.url,
      headers: { ...req.headers, authorization: '[REDACTED]' }
    }),
    err: pino.stdSerializers.err,
    user: (user) => ({
      id: user.id,
      email: user.email,
      role: user.role
      // password intentionally omitted
    })
  },
  redact: ['req.headers.cookie', 'user.password']
});

logger.info({ user: { id: 1, email: 'a@b.com', password: 'secret' } }, 'User login');
// Output: {"user":{"id":1,"email":"a@b.com"},"msg":"User login"}

pino-http Middleware Options: customLogLevel and genReqId

The pino-http middleware integrates Pino with HTTP servers like Express. It provides options to customize log levels per request and generate custom request IDs. Use customLogLevel to set log level based on response status (e.g., 4xx as warn, 5xx as error). Use genReqId to generate correlation IDs that match your existing tracing system. The middleware automatically logs request start and response finish. Combine with AsyncLocalStorage for full context propagation. Avoid logging request bodies in production unless absolutely necessary; use autoLogging: false or a custom serializer.

const express = require('express');
const pino = require('pino');
const pinoHttp = require('pino-http');
const crypto = require('crypto');

const logger = pino();

const httpLogger = pinoHttp({
  logger,
  customLogLevel: (res, err) => {
    if (res.statusCode >= 500 || err) return 'error';
    if (res.statusCode >= 400) return 'warn';
    return 'info';
  },
  genReqId: (req) => req.headers['x-request-id'] || crypto.randomUUID(),
  autoLogging: {
    ignore: (req) => req.url === '/health'
  }
});

const app = express();
app.use(httpLogger);

app.get('/api', (req, res) => {
  res.json({ ok: true });
});

app.listen(3000);

Winston exitOnError Handling

By default, Winston's exitOnError is false, meaning unhandled errors in transports won't crash the process. However, you can set it to true to exit on transport errors, which is useful in some production scenarios. More importantly, you should handle uncaught exceptions and unhandled rejections separately using Winston's exception and rejection handlers. Use winston.exceptions.handle() and winston.rejections.handle() to log these critical errors before exiting. This ensures you don't lose error logs when the process crashes. Combine with a transport that writes to a file or a remote service. Always test your error handling by simulating crashes in a staging environment.

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.Console()
  ],
  exitOnError: false // default, but explicit
});

// Handle uncaught exceptions
logger.exceptions.handle(
  new winston.transports.File({ filename: 'exceptions.log' })
);

// Handle unhandled rejections
logger.rejections.handle(
  new winston.transports.File({ filename: 'rejections.log' })
);

// Simulate an uncaught exception
setTimeout(() => {
  throw new Error('Something went wrong');
}, 1000);

Centralized Logging Aggregation Specifics

Centralized logging aggregates logs from multiple services into a single platform (e.g., ELK, Datadog, Splunk). For Node.js, the key is to send structured JSON logs to stdout and let a log shipper (Filebeat, Fluentd) forward them. Avoid writing to files in containers; use stdout. For Winston, use a transport like winston-elasticsearch or winston-datadog. For Pino, use pino-socket or pino-datadog. Ensure logs include service name, environment, and version for filtering. Use a consistent log format across all services. Implement log sampling for high-volume services to reduce costs. Always buffer logs and handle network failures gracefully.

const pino = require('pino');
const pinoDatadog = require('pino-datadog');

const stream = pinoDatadog.createWriteStream({
  apiKey: process.env.DD_API_KEY,
  service: 'my-service',
  ddsource: 'nodejs',
  ddtags: 'env:production',
  bufferSize: 1000, // buffer up to 1000 logs
  sync: false // async for performance
});

const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  base: {
    service: 'my-service',
    env: process.env.NODE_ENV
  }
}, stream);

logger.info('Service started');