spdlog: Fast C++ Logging with Rotating Files, Async Mode, and fmt Formatting

What spdlog Solves and Who Uses It

spdlog is a C++ logging library designed to be fast and straightforward to add to an existing project. The README describes two installation modes: header-only, where the developer copies the include/spdlog directory into their build tree and uses any C++11 compiler, and compiled, where a build step produces a separate library with faster compile times for the consuming project. The compiled mode is recommended in the README.

The library targets C++ developers who need structured, leveled logging across a range of sinks: files that rotate by size or time, the system console with color output, syslog on Linux, Windows event log, and Qt widget outputs. The same codebase runs on Linux, FreeBSD, OpenBSD, Solaris, AIX, Windows with MSVC 2013 and later, macOS with clang 3.5 and later, and Android. This platform breadth means the logging code can be shared across a desktop application and its Android port without switching libraries.

Installing via Package Managers or from Source

The README lists package managers for multiple platforms. On Debian and Ubuntu, the package is libspdlog-dev. On macOS, Homebrew and MacPorts both carry it. On Fedora, it is available via dnf. On Arch Linux, it is in the pacman repository. Cross-platform build systems are covered: vcpkg installs it as spdlog, conan installs it as spdlog/[*], conda installs it via conda-forge, and build2 supports it with a depends declaration.

Building from source uses cmake and follows this sequence:

git clone https://github.com/gabime/spdlog.git
cd spdlog && mkdir build && cd build
cmake .. && cmake --build .

The example/CMakeLists.txt file in the repository shows how to link spdlog into a consuming project via cmake. The header-only installation requires no build step: copying the include/spdlog directory is sufficient for a C++11 or later compiler.

Basic Usage: Loggers, Sinks, and Log Levels

spdlog uses a global logger for convenience and named loggers for more structured applications. The basic usage example from the README shows global-level calls:

#include "spdlog/spdlog.h"
int main()
{
    spdlog::info("Welcome to spdlog!");
    spdlog::error("Some error message with arg: {}", 1);
    spdlog::set_level(spdlog::level::debug);
    spdlog::debug("This message should be displayed..");
}

Named loggers are created with functions that return a shared pointer and are registered in a global registry. The README shows retrieving a registered logger with spdlog::get("console"). Log levels can be changed at runtime, and the README states they can also be modified at compile time. The library supports loading log levels from command-line arguments or environment variables, which is useful for changing logging verbosity in production without recompiling.

The multi-threaded and single-threaded variants of each sink are distinguished by the _mt and _st suffixes. The README's multi-sink example uses stdout_color_sink_mt for thread-safe console output and basic_file_sink_mt for thread-safe file output, combining them into a single logger that writes to both.

Rotating Files, Daily Files, and Backtrace

The file sink options cover two rotation strategies. Rotating files cap the log file at a maximum byte size and keep a fixed number of rotated files. The README example creates a rotating logger with a 5 MB cap and 3 kept files:

auto max_size = 1048576 * 5;
auto max_files = 3;
auto logger = spdlog::rotating_logger_mt("some_logger_name", "logs/rotating.txt", max_size, max_files);

Daily files create a new log file at a configured time each day. The README example creates a daily logger that rolls at 2:30 AM.

The backtrace feature stores debug messages in a ring buffer without writing them immediately. This is useful when debug logging is too verbose to leave on permanently but occasionally needed for diagnosis. The README example stores the last 32 messages and flushes them to the log on demand:

spdlog::enable_backtrace(32);
spdlog::dump_backtrace();

A periodic flush can be configured to write buffered log data every N seconds. The README warns that this feature should only be used with thread-safe loggers (the _mt variants).

Async Mode and fmtlib Formatting

The README lists asynchronous mode as an optional feature. In async mode, log calls return immediately after placing the message in a queue, and a background thread handles the actual sink writes. This is useful for high-throughput applications where synchronous I/O on the logging path would add measurable latency. The README does not show an async example inline, but it is documented as a supported feature.

The formatting system uses fmtlib, which is the same library underlying C++20's std::format. Formatting supports positional arguments, padding, width, fill characters, and numeric bases. The README shows examples of hex, octal, and binary integer formatting, left-aligned strings, and floating-point precision. Binary data can also be logged in hexadecimal format using spdlog::to_hex, with options to control spacing, ASCII display, and line splitting. The fmtlib dependency means the formatting is well-tested and consistent with a widely used standard, but it also means teams who want to avoid fmtlib cannot use spdlog without replacing the formatting layer.

spdlog vs glog and Boost.Log

glog is Google's C++ logging library and the most common alternative encountered in codebases that follow Google's internal practices. The design difference is in the API and intended use: glog is built around severity-level macros (LOG(INFO), LOG(WARNING)) and CHECK assertion macros, with output defaulting to files in the system temporary directory. spdlog uses fmtlib-style format strings and emphasizes configurable sinks rather than fixed file outputs. Teams migrating from glog to spdlog will need to replace LOG() macros with spdlog calls.

Boost.Log is the logging component of the Boost library ecosystem. It is more complex than spdlog, supporting log record attributes, filters, and a pipeline-based architecture. The tradeoff is that Boost.Log adds a dependency on the broader Boost library or at least its subset, and the initialization code is more verbose. spdlog's goal is a simpler API that covers the common cases without the full Boost infrastructure.

License Situation and Release History

The repository's license field in the GitHub metadata is listed as NOASSERTION, which means the automated license detection did not produce a classification. The LICENSE file in the repository holds the authoritative text. Teams with license compliance workflows should read that file directly rather than relying on the NOASSERTION label.

The most recent tagged release is v1.17.0, published on 2026-01-04. Prior releases include v1.16.0 from 2025-10-11 and v1.15.3 from 2025-05-09. The repository received its last push on 2026-09-25 and is not archived. The default branch is v1.x, and the build is tested on Linux, Windows, and macOS according to the GitHub Actions workflows listed in the README badges.

Editorial conclusion

C++ developers who need a logging library that installs quickly through a package manager, supports rotating log files, and uses fmtlib syntax should find spdlog directly applicable. Teams working on Android, macOS, Windows, or Linux can use it since the platform list in the README covers all of these. The license field in the repository is marked NOASSERTION, so teams with license compliance requirements should verify the actual license text in the LICENSE file before adopting. The most recent release is v1.17.0 from 2026-01-04, and the repository received its last push on 2026-09-25.

Frequently asked questions

Official sources

1. gabime/spdlog on GitHub
2. Issues
3. README
4. Releases