Skip to content
A fully featured logging framework for R
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs prep for release Jun 13, 2019
inst prep for release Jun 13, 2019
man-roxygen doc and finetuning of should_flush behaviour Jan 6, 2019
man prep for release Jun 13, 2019
revdep add revdep May 30, 2019
tests Adds assert_namespace calls to Appender initializers where appropriate; Jun 11, 2019
vignettes prep for release Jun 13, 2019
.covrignore added tests for add/remove/set appenders for AppenderBuffer and clean… Dec 25, 2018
.gitignore doc / cleanup Mar 22, 2019
DESCRIPTION prep for release Jun 13, 2019
LICENSE prep for internal release Nov 29, 2018
NAMESPACE implements format.logger_tree and adds logger_tree to pkgdown functio… Jun 10, 2019
README.Rmd Improves Optional Dependencies section in the README Jun 11, 2019
_pkgdown.yml implements format.logger_tree and adds logger_tree to pkgdown functio… Jun 10, 2019
codecov.yml prep for release Jun 13, 2019


CRAN status Lifecycle: maturing Travis build status Codecov test coverage

lgr is a logging package for R built on the back of R6 classes. It is designed to be flexible, performant and extensible. The package vignette contains a comprehensive description of the features of lgr (some of them unique among R logging packages) along with many code examples.

Users that have not worked with R6 classes before, will find configuring Loggers a bit strange and verbose, but care was taken to keep the syntax for common logging tasks and interactive usage simple and concise. User that have experience with shiny, plumber, python logging or Apache Log4j will feel at home. User that are proficient with R6 classes will also find it easy to extend and customize lgr, for example with their own appenders Loggers or Appenders.


  • Hierarchical loggers like in log4j and python logging. This is useful if you want to be able to configure logging on a per-package basis.
  • An arbitrary number of appenders for each logger. A single logger can write to the console, a logfile, a database, etc… .
  • Allow for custom fields in log events. As opposed to many other logging packages for R a log event is not just a message with a timestamp, but an object that can contain arbitrary data fields. This is useful for producing machine readable logs.
  • Vectorized logging (so lgr$fatal(capture.output(iris)) works)
  • Lightning fast in-memory logs for interactive use.
  • Appenders that write logs to a wide range of destinations:
    • databases (buffered or directly)
    • email or pushbullet
    • plaintext files (with a powerful formatting syntax)
    • JSON files with arbitrary data fields
    • Rotating files that are reset and backed-up after they reach a certain file size or age
    • memory buffers
    • (colored) console output
  • Optional support to use glue instead of sprintf() for composing log messages.


To log an event with with lgr we call lgr$<logging function>(). Unnamed arguments to the logging function are interpreted by sprintf(). For a way to create loggers that glue instead please refer to the vignette.

lgr$fatal("A critical error")
#> FATAL [08:25:07.182] A critical error
lgr$error("A less severe error")
#> ERROR [08:25:07.211] A less severe error
lgr$warn("A potentially bad situation")
#> WARN  [08:25:07.221] A potentially bad situation
lgr$info("iris has %s rows", nrow(iris))
#> INFO  [08:25:07.223] iris has 150 rows

# the following log levels are hidden by default
lgr$debug("A debug message")
lgr$trace("A finer grained debug message")

A Logger can have several Appenders. For example, we can add a JSON appender to log to a file with little effort.

tf <- tempfile()
lgr$add_appender(AppenderFile$new(tf, layout = LayoutJson$new()))
lgr$info("cars has %s rows", nrow(cars))
#> INFO  [08:25:07.239] cars has 50 rows
#> {"level":400,"timestamp":"2019-06-11 08:25:07","logger":"root","caller":"eval","msg":"cars has 50 rows"}

By passing a named argument to info(), warn(), and co you can log not only text but arbitrary R objects. Not all appenders handle such custom fields perfectly, but JSON does. This way you can create logfiles that are machine as well as (somewhat) human readable.

lgr$info("loading cars", "cars", rows = nrow(cars), cols = ncol(cars))
#> INFO  [08:25:07.258] loading cars {rows: 50, cols: 2}
cat(readLines(tf), sep = "\n")
#> {"level":400,"timestamp":"2019-06-11 08:25:07","logger":"root","caller":"eval","msg":"cars has 50 rows"}
#> {"level":400,"timestamp":"2019-06-11 08:25:07","logger":"root","caller":"eval","msg":"loading cars","rows":50,"cols":2}

For more examples please see the package vignette and documentation

See lgr in action

lgr is used to govern console output in my shiny based csv editor shed

# install.packages("remotes")

# log only output from the "shed" logger to a file
logfile <- tempfile()

# edit away and watch the rstudio console!
lgr$info("starting shed")
lgr$info("this will not end up in the log file")


# cleanup

Development status

The api of lgr is stable and safe for use. The internal implementation of the database logging features still needs some refinement, and if you are using lgr with a database, I would be grateful for any kind of feedback.[1]

lgr is currently very actively developed, and feature requests are encouraged.


R6: The R6 class system provides the framework on which lgr is built and the only Package lgr will ever depend on. If you are a package developer and want to add logging to your package, this is the only transitive dependency you have to worry about, as configuring of the loggers should be left to the user of your package.

Optional dependencies

lgr comes with a long list of optional dependencies that make a wide range of appenders possible. You only need the dependencies for the Appenders you actually want to use. Care was taken to choose packages that are slim, stable, have minimal dependencies, and are well maintained :

Extra appenders (and layouts):

  • jsonlite for JSON logging via LayoutJson. JSON is a popular plaintext based file format that is easy to read for humans and machines alike.
  • rotor for log rotation via AppenderFileRotating and co.
  • DBI for logging to databases. lgr is confirmed to work with the following backends:
    • RSQLite,
    • RMariaDB for MariaDB and MySQL,
    • RPostgres,
    • RJDBC for DB2, and
    • odbc also for DB2. In theory all DBI compliant database packages should work. If you are using lgr with a database backend, please report your (positive and negative) experiences, as database support is still somewhat experimental.
  • data.table for fast in-memory logging with AppenderDt, and also by all database / DBI Appenders.
  • gmailr or sendmailR for email notifications.
  • RPushbullet for push notifications.
  • glue for a more flexible formatting syntax via LoggerGlue and LayoutGlue.

Other extra features:

  • yaml for configuring loggers via YAML files
  • crayon for colored console output.
  • whoami for guessing the user name from various sources. You can also set the user name manually if you want to use it for logging.
  • desc for the package development convenience function use_logger()
  • cli for printing the tree structure of registered loggers with logger_tree()

Other Suggests (future, future.apply) do not provide extra functionality but had to be included for some of the automated unit tests run by lgr.


You can install lgr from CRAN


Or you can install the current development version directly from github



The long term goal is to support (nearly) all features of the python logging module. If you have experience with python logging or Log4j and are missing features/appenders that you’d like to see, please feel free to post a feature request on the issue tracker.


  1. The only database logging I can currently test extensively is DB2 via RJDBC. I do not recommend this setup if you have other options.
You can’t perform that action at this time.