Flogger is a fluent logging API for Java, published under the Apache-2.0 licence by Google, that replaces a wide field of competing Java logging APIs with one unified, self-documenting interface.

What it is

Flogger is a Java logging library built around a fluent interface, in which a logging statement is composed as a chain of method calls rather than as a single call with a long parameter list. A typical statement reads logger.atInfo().withCause(exception).log("Log message with: %s", argument);, and it lives in the Java ecosystem as a Maven artifact published to Maven Central. It is not a log output backend; it is the API that application code calls, with a separate system backend supplying the actual log transport at runtime.

The concrete problem it solves is API fragmentation. Google's codebase grew to contain many different debug logging APIs, each with its own benefits and issues, so developers had to switch between APIs as they moved between projects, and differences between those APIs caused confusion and bugs. Flogger is the result of an attempt to create a unified logging API suitable for the vast majority of Java projects inside Google. After most Google Java code was switched to Flogger, thousands of bugs were fixed and the cost of learning a new logging API per project was eliminated. Flogger is now the sole recommended Java logging API within Google.

Key capabilities

• Logging at disabled levels is effectively free, so fine-grained log statements can be added without performance worry.
• High performance for enabled log statements, per the README's stated benefits.
• Fluent chaining that accommodates present and future features without combinatorial explosion and without requiring separate logging façades.
• Rate limiting through atMostEvery(30, SECONDS), which suppresses repeated messages within a time window.
• Deferred argument evaluation via lazy(() -> doExpensiveCalculation()), so expensive work runs only if the message is actually emitted.
• Cause attachment through withCause(exception), and level entry points such as atInfo() and atSevere().
• Message formatting with Java's printf format specifiers, including %s, %d and %016x.

Who uses it and how

• Large Java monorepos where many teams share one logging interface and developers move between projects, avoiding per-project API relearning.
• Applications that need many fine-grained log statements active in source but effectively free when their level is disabled.
• Services that need to throttle noisy messages, using atMostEvery around high-frequency code paths.
• Codebases that want expensive log arguments computed only on demand, using lazy(...) rather than pre-built strings.
• Teams already inside the Google Java ecosystem, where a GoogleLogger variant of FluentLogger exists for use in Google's codebase.

Getting started

Add com.google.flogger:flogger and com.google.flogger:flogger-system-backend as dependencies, with the system backend needed only at runtime by the module that builds the app or binary. Then import com.google.common.flogger.FluentLogger, create a private static final FluentLogger logger = FluentLogger.forEnclosingClass();, and either rely on the transitive binding or pick a backend such as the SLF4J one.

How it compares

The facts provided do not name any paid products that Flogger replaces, and they do not name any specific competing open-source logging API either, so it stands alone in this registry rather than sitting in a documented comparison set. What the facts do establish is a contrast against the alternatives in general terms: the Java Core Libraries Team, the Guava maintainers, concluded that Flogger was not slightly better than those alternatives but much better. That conclusion is the basis for Flogger being the sole recommended Java logging API within Google.

When to use it — and when not to

A self-hoster is not operating a service here, since Flogger is a library that ships as Maven artifacts, so the operational burden falls on selecting and configuring a backend and keeping the runtime dependency on flogger-system-backend wired into the built binary. Avoid it if the project is not Java, if the team is unwilling to leave an existing logging API behind, or if the fluent style is unwanted. Note also that the registry record is honest about maturity signals rather than feature gaps: 53 open issues, but an active codebase with a last push in September 2026, a maintained homepage, and published Javadocs and CI badges.

logger.atInfo().withCause(exception).log("Log message with: %s", argument);

logger.atSevere()
    .atMostEvery(30, SECONDS)
    .log("Value: %s", lazy(() -> doExpensiveCalculation()));

import com.google.common.flogger.FluentLogger;

private static final FluentLogger logger = FluentLogger.forEnclosingClass();

logger.atInfo().withCause(exception).log("Log message with: %s", argument);