Awesome Open Source
Awesome Open Source


A structured logging framework for JavaScript, inspired by Serilog.

|Branch|Status| |---|---|---| |master|Build Status| |dev|Build Status|

Basic Example

const structuredLog = require('structured-log');

const log = structuredLog.configure()
  .writeTo(new structuredLog.ConsoleSink())
  .create();'Hello {Name}!', 'Greg');

The above code will print the following to the console:

[Information] Hello Greg!


structured-log is distributed through npm and Bower. Run the following:

npm i --save structured-log

Or, using Bower:

bower install structured-log

Note: structured-log embeds a polyfill for Object.assign, but you will need to bring your own Promise polyfill to use it in an environment that doesn't support Promises natively.


Configuring structured-log is a straightforward process, going through three steps. First, we initialize a new logging pipeline configuration by calling configure():

const log = structuredLog.configure()

The second step is the main step. Configuration of different filters and targets is done by chaining methods together in a fluent syntax. Events flow through the pipeline from top to bottom, so new filters and enrichers can be inserted between the different sinks to build a highly controllable pipeline.

  .writeTo(new structuredLog.ConsoleSink())
  .writeTo(new OtherExampleSink({ url: '' }))

The chain is closed by calling create(), which instantiates a new logger instance based on the pipeline configuration.


// The logger is ready for use!
log.verbose('Hello structured-log!');

Log Levels

There are 6 log levels available by default, in addition to a setting to disable logging completely. In decreasing order of severity (with descriptions borrowed from Seq):

Label Description Bitfield
off When the minimum level is set to this, nothing will be logged. 0
fatal Critical errors causing complete failure of the application. 1
error Indicates failures within the application or connected systems. 3
warning Indicators of possible issues or service/functionality degradatio. 7
information Events of interest or that have relevance to outside observers. 15
debug Internal control flow and diagnostic state dumps to facilitate pinpointing of recognised problems. 31
verbose Tracing information and debugging minutiae; generally only switched on in unusual situations. 63

The log levels can also be represented as bitfields, and each log level also includes any levels of higher severity. For example, warning will also allow events of the error level through, but block information, debug and verbose.

A minimum level can be set anywhere in the pipeline to only allow events matching that level level or lower to pass further through the pipeline.

The below examples will all set the minimum level to warning:

// or
// or

There is no minimum level set by default, but a common choice is Information. Note that if a restrictive level is set early in the pipeline, and a more permissive level is set further down, the events that are filtered out by the more restrictive level will never reach the more permissive filter.

The Logger object contains shorthand methods for logging to each level.

log.fatal('Application startup failed due to a missing configuration file');
log.error('Could not parse response message');
log.warn('Execution time of {time} exceeded budget of {budget}ms', actualTime, budgetTime);'Started a new session');
log.debug('Accept-Encoding header value: {acceptEncoding}', response.acceptEncoding);
log.verbose('Exiting getUsers()');

You can also pass an error object as the first argument to any of the logging methods, which will pass it along with the event and allow it to be processed by the pipeline:

try {
  // something that fails here
 } catch (error) {
   log.error(error, error.message);

Dynamically controlling the minimum level

You can also control the minimum level dynamically using the DynamicLevelSwitch class. Pass an instance to the minLevel() function:

const dynamicLevelSwitch = new DynamicLevelSwitch();

// ...


You can then call the same shorthand methods as those present on the minLevel object (error(), debug() etc.) to dynamically change the minimum level for the subsequent stages in the pipeline.

logger.debug('This message will be logged');
logger.debug('This message won\'t');


A sink is a recipient for log events going through the pipeline, and is generally used to publish events to some external source such as the developer console, file system or an online service.

To add a sink as a target for log events in the pipeline, pass an instance to the writeTo() function.

  .writeTo(new ExampleSink())

The Logger object that's created with the create() method is also a valid sink, so you can pass it to another pipeline.

const logger1 = structuredLog.configure()
  // ...

const logger2 = structuredLog.configure()

Built-in sinks

Name Description
ConsoleSink Outputs events through the console object in Node or the browser.

3rd party sinks

Name Description
SeqSink Outputs events to a Seq server.


You can filter which events are passed through the pipeline using the filter() function. It takes a single function parameter that will be used to test events going into the filter, and if it returns true, the events will be allowed to continue through the pipeline.

The below example will filter out any log events with template properties, only allowing pure text events through to the next pipeline stage.

  .filter(logEvent => === 0)

The predicate should take a log event as its only parameter, and return true or false.


Log events going through the pipeline can be enriched with additional properties by using the enrich() function.

    'version': 2,
    'source': 'Client Application'

You can also pass a function as the first argument, and return an object with the properties to enrich with. This can be useful to dynamically add properties based on the current context or state of the application.

const state = {
  user: null

// ...

  .enrich(() => ({ user: }))


Errors in the logger are suppressed by default. To disable suppression, and allow errors to be propagated to the environment, use the suppressErrors() function to set suppression to false.


This setting is global for the pipeline, so if it is called multiple times in the configuration chain, the value of the last call will be used.

Only errors throw in the logging pipeline will be suppressed. Errors that occur during configuration will always propagate.

Console Sink

The ConsoleSink, which outputs event to the Node.js or browser console, is provided by default. The following line creates a new instance that can be passed to the logger configuration:

var consoleSink = new structuredLog.ConsoleSink({ /* options */ });

The options object is optional, but can be used to modify the functionality of the sink. It supports the following properties:

Key Description
console An object with a console interface (providing log(), info(), etc.) that will be used by the sink when writing output. The global console object will be used by default.
includeProperties If true, the properties of the log event will be written to the console in addition to the message. Defaults to false.
includeTimestamps If true, timestamps will be included in the message that is written to the console. Defaults to false.
restrictedToMinimumLevel If set, only events of the specified level or higher will be output to the console.

Get A Weekly Email With Trending Projects For These Topics
No Spam. Unsubscribe easily at any time.
Typescript (246,891
Logging (3,347
Logger (1,628
Serilog (227
Related Projects