Spring boot multiple log files
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
If you want multiple log files in Spring Boot, you usually move beyond the simple logging.file.* properties and configure Logback directly. Spring Boot uses Logback by default, and multiple files are handled by defining multiple appenders and wiring specific loggers or the root logger to the appenders you want.
Why Properties Alone Are Not Enough
Spring Boot properties are convenient for basic logging, but they are aimed at simple cases such as one file and one console output. As soon as you need:
- a separate error log
- package-specific log files
- different rolling policies per file
you should create a logback-spring.xml file in src/main/resources.
That gives you access to native Logback configuration while still letting Spring Boot resolve properties and profiles.
Define Multiple File Appenders
Here is a basic example with one general application log and one error-only log.
With this setup:
- all INFO-and-above logs go to
app.log - only ERROR-and-above logs go to
error.log
That is the standard pattern: define multiple appenders, then attach them where needed.
Route Specific Packages to Their Own File
You can also give one package or component its own log file.
additivity="false" is important when you want those logs to go only to the dedicated file instead of also bubbling up into the root logger appenders.
This is a common setup for access logs, audit logs, or noisy subsystems that deserve their own file.
In real applications you will usually add rolling policies as well, so that each file rotates by size or date instead of growing forever. The exact rolling strategy is a Logback concern, but it should be designed together with the multi-file layout.
Keep the Configuration Understandable
Multiple log files are helpful only if they stay understandable operationally. Good questions to answer up front are:
- which logs belong in the root file
- which package should have a dedicated file
- whether duplicate logging is acceptable
- how rolling and retention should work
Without those decisions, multiple appenders can quickly turn into duplicated output and confusing log volume.
That is why many teams start with one root file plus one or two carefully chosen specialized files, instead of trying to split every package into its own log target from day one.
Common Pitfalls
- Expecting
application.propertiesalone to handle complex multi-file logging cleanly. - Forgetting
additivity="false"and accidentally duplicating messages across files. - Sending everything to many appenders and creating noisy, redundant log files.
- Configuring multiple files without thinking about rolling policies and disk usage.
- Creating dedicated log files for too many packages and making the logging layout harder to operate than the application itself.
Summary
- For multiple log files in Spring Boot, use
logback-spring.xml. - Define one appender per log destination and attach them to the root logger or specific package loggers.
- Use filters for level-based routing and
additivity="false"for isolated package logs. - Spring Boot properties are fine for simple logging, but native Logback config is the right tool for multi-file setups.
- Clear appender design matters as much as the XML syntax itself.
Related reading
- Spring Boot multiple SLF4J bindings
- Spring Boot requests to re-run your application with 'debug' enabled - how do I?
- Spring boot show sql parameter binding?
- Spring boot startup error for AWS application There is not EC2 meta data available
- Spring Boot Multiple similar ConfigurationProperties with different Prefixes
- Spring Boot MVC Multi-Module Executeable jar
- Spring Boot Unit Test ignores logging.level
- Spring Boot War deployed to Tomcat

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.