What JS Logging library / tool do you use?

I am trying to decide on what logging module to try out for my next project. I'd love the dev community's input on:

A) What logging lib you use
B) Whether you structure your logs (and how)
C) Where you store your logs or any other logging infra you have

I have been using Winston, but I would like something that supports structured logging out of the box. The general ecosystem on NPM seems to be pretty split, and some options seem to be popular but un-maintained.

Did you find this post useful? Show some love!

There is only one thing I use:


And I reset (and remove) my logs after the code has been proven stable. :-) Generally, logging should remain a debugging feature. The users won't need it.

I also do this. But I’m curious about other answers in the thread.

Since I'm just starting learning node I came to this post with some hesitation since I really didn't know if console.log() was an acceptable answer. Thanks for the clarification. hahaha

For those who use simple console.log() and VS Code as editor, try out wrap-console-log extension.

If you'd like to color your log try chalk.

Other than console.log(), there have been morgan, winston, pino and at least hundreds of others.

But, I am very surprised to see no one mentioned debug, it has 22,914,644 weekly downloads as of right this comment.

  • I can filter out and specify different keywords I put beforehand, can use wildcards for multiple keywords/namespace
  • Can have namespace colors
  • Even works on web browser with colorized output
  • can show ms diff between last msg
  • ...lots of other cool features like streams and the list goes on
  • and most importantly it is actively developed

Though it is more of a debugging tool than a logging tool, we do have to log a lot while trying to debug, or in most case debugging is the only goal for logging.

There are obvious gotchas, but who cares as long as I can get to see what I wanted to see.

debug module borks when minimized

You need to configure the compression to let some optimizations through

I also couldnt get it to work on an isomorphic app. Minimizing for node.js and tje web require 2 different approaches

On the front end, I mainly use console.log; however, I turn the logging on and off via an environment variable before I compile. If the logging is turned off, the log function does a no op.

const logFunc = (process.env.NODE_ENV === 'development') ? console.log : () => {};

class Utility {

     static log(...args) {
           // Usually I do some normalization and enhancement here by map over the args
           const enhancedArgs = args.map(arg => JSON.stringify(arg, null, 2))

           // Call the logFunc with console
           logFunc.apply(console, enhancedArgs)


On the server side, I use winston and morgan.

This is a really good idea that I had never thought of for JS. Is () => {} really a no-op or is there just less overhead? In C, you can use (void) 0 to denote a no-op which would get optimized out in the compiler, but in JS you're interpreted.

console.log(), but are you using node? Noticed it in your tag. If that's the case you can require fs and write logs out to your filesystem. Also check out console.table for iterable objects, and also console.assert

I don't have console.alert. Did you mean .assert?

Yes. Sorry, on my phone when I punched that out. Also look into console.error()

console.log and node app.js > app.log work fine most of the time.

Sometimes, if I need to filter logs and stuff, I write them as json objects instead of plain files and create a very simple wrapper over console.log, but I've never had the need to do anything very elaborated.

I've written two posts on logging in JavaScript that might be helpful:
Should you use a logging framework or console.log() in Node?

^ In this one I make the argument that often console.log() and console.error() are enough to get the job done, unless you have a use case for custom log levels, for writing to different outputs/locations (I recommended against doing this), or need the ability to toggle logs on and off.

If I do have that use case I use Winston as it's pretty well supported.

Why should your Node.js application not handle log routing?

^ this one hopefully helps answer your question about storing logs and logging infrastructure

I always write to stdout/stderr (the console module writes here) as it's really easy for Docker or other containers to pick up the logs from there and route them wherever you need to (Splunk, a database, etc.).

In a container/distributed/cloud environment it becomes much easier to manage the logs and adheres to the 12 Factor best practices for logging.

In this way, the log routing is decoupled from the concerns of the application. All the application then cares about is writing to console, and infrastructure-wise, the container picks up the logs and takes care of them from there.

I'am using log4js in my project. But most of time I still using console.log() for debugging

I like using this, too. Log levels are super helpful

my use cases :

1- in case of using Docker
A) Winston to log and store in txt file
B) structure based on the Service name, and Environment (stg or production)
C) Store in txt file, use filebeat to harvest and push to Logstash to index and store in Elastic search. then visualise it Kibana (ELK stack)

2- in case of using AWS Lambda
A) simple "console.log()"
B) not really
C) just use AWS CloudWatch

A) I use a combination of morgan for request logging, and Winston for error logs.

B) I structure my logs into information logs, warning logs, request logs, and error logs.

  • The information logs are used for things like user sign-in, database modifications, and algorithm analysis.
  • Warning logs are things like the user was denied access, A resource is using up too much memory or taking too long, or a result that doesn't break the system, but could be a problem for the user.
  • Error logs are reserved for runtime errors or anything where a system actually failed to perform its job.
  • The request logs are handled by Morgan and they mainly log the request made to the server, the parsed query (using GraphQL), and the response to the user.

C) I store my logs in a logs folder on the production server. They are organized into 3 files based on the level of severity, and each log entry is prepended with a time stamp, and the userId if applicable.

Winston has been my daily driver for a while.
Having different transport methods, easily changing the logging level and the handling uncaught exceptions makes debugging a lot better!

This is a game changer, specially on old code!

Seems like a lot of people use winston. I primarily use serilog (.NET), the reason I love it and bring it up is because it's a fully-structured logger. I can't speak to winston's capabilities, but I know bunyan offers similar features in node which I highly recommend finding.

I used winston, bunyan and pino (also console.log 😅) on nodejs apps to log all application activity and storing using some "log rotate" plugin.

same here! winston, bunyan and pino for da win!

Haven't heard of Winston before this post. Looks really cool for creating log files based on the console statements used in the code!

I have used and enjoyed bunyan. Used in combination with bunyan-format it improved the project.

You can see it used in my project here:

We are using loglevel github.com/pimterry/loglevel to log errors and to debug code. Currently not storing the logs. All the "debug" logs are disabled in production builds.

What will be the API you want for the logger ?

like you, I've been using Winston (am still using it)

Winston, logging to console in development and console plus elastic stack in production.

I like the feature of sending JSON to elastic with the resulting possibility of organizing (filtering, sorting, searching, columns, ...) based on those JSON keys.

Classic DEV Post from Jul 20

The Essential Skill of a Developer

Being a developer requires specific skills and tools. I realized what the essential skill for one developer is.

Daniel Golant
Join dev.to

Better understand your code.