Why Does My Logback Configuration Duplicate Logs? Common Pitfalls and Fixes

Many developers copy Logback configuration files from other projects or blogs without fully understanding each option, which often leads to duplicated log entries, unnecessary disk usage, and extra load on log‑collection systems.

1. Logger inheritance misconfiguration

The most frequent cause is attaching the same <appender> to both a specific logger and the <root> logger. Because the logger inherits from <root>, each log event is written twice—once by the logger and once by the root.

Example snippet (simplified):

<logger name="org.javaedge.logging" level="DEBUG">
    ...
</logger>
<root level="INFO">
    ...
</root>

Fix: remove the duplicate appender from the logger or set additivity="false" on the logger so it does not inherit the root’s appender.

2. LevelFilter configuration error

Another common mistake is using LevelFilter without specifying onMatch and onMismatch. In this case the filter does nothing, and all logs above the configured level are recorded, producing unexpected content in log files.

Observed behavior:

info.log contains INFO, WARN and ERROR logs (should contain only INFO).

error.log contains both WARN and ERROR logs, leading to duplicate collection.

Because LevelFilter defaults to passing the event to the next filter, the intended level restriction is ineffective.

3. ThresholdFilter vs. LevelFilter

ThresholdFilter

simply compares the event’s level with the configured threshold. If the event level is greater than or equal to the threshold, it returns NEUTRAL (allowing the next filter to run); otherwise it returns DENY , blocking the event. LevelFilter requires explicit onMatch and onMismatch actions. Without them, the filter behaves like a no‑op, causing INFO‑and‑above logs to be recorded.

4. Correcting LevelFilter

Set onMatch="ACCEPT" to allow the desired level (e.g., INFO) and onMismatch="DENY" to reject all other levels. After this change, the _info.log file contains only INFO‑level entries, eliminating duplication.

<filter class="ch.qos.logback.classic.filter.LevelFilter"
        level="INFO"
        onMatch="ACCEPT"
        onMismatch="DENY"/>

5. Practical impact

In many companies, automated ELK pipelines collect logs from both console and file outputs. Developers often test locally without checking the file output, while production environments may hide duplicate logs due to limited server access, making the problem hard to spot.

By understanding logger inheritance, correctly configuring additivity, and properly setting filter actions, duplicate logging can be avoided, leading to cleaner log files and reduced storage and processing overhead.