Introduction

When Spring Boot does not seem to load logback-spring.xml, the problem is usually one of four things: the file is not on the runtime classpath, another logging config is taking precedence, Logback is not actually the active logging system, or the XML uses Spring-specific features in a way that Logback loads too early to understand. The fix is usually straightforward once you check those possibilities in the right order.

What Spring Boot Actually Looks For

With Logback on the classpath, Spring Boot can pick up logging configuration from standard locations such as:

• 'classpath:logback-spring.xml'
• 'classpath:logback.xml'

The -spring variant matters because it enables Spring Boot’s Logback extensions such as springProfile and springProperty.

A normal project layout should place the file here:

src/main/resources/logback-spring.xml

If it is somewhere else, Boot will not find it automatically unless you point to it explicitly.

A Minimal Working Example

This is a minimal logback-spring.xml that Spring Boot should load cleanly:

1<?xml version="1.0" encoding="UTF-8"?>
2<configuration>
3    <include resource="org/springframework/boot/logging/logback/defaults.xml" />
4    <include resource="org/springframework/boot/logging/logback/console-appender.xml" />
5
6    <root level="INFO">
7        <appender-ref ref="CONSOLE" />
8    </root>
9</configuration>

If even a file this simple is ignored, the issue is usually classpath placement, dependency conflicts, or a different config file being chosen first.

Check for Competing Configuration Files

One very common cause is having both of these present:

• 'logback.xml'
• 'logback-spring.xml'

That can create confusion, especially if one file is packaged and the other is the one you are editing. If you want Spring Boot extensions, keep logback-spring.xml and remove unnecessary competing logging configs.

Also check for these other possibilities:

• 'logging.config property pointing somewhere else'
• a different logging implementation such as Log4j2 on the classpath
• test resources overriding main resources

If another config location wins first, your logback-spring.xml may be fine but never used.

Use logging.config When Needed

If the file is not in the default location, point Spring Boot at it explicitly.

In application.properties:

logging.config=classpath:custom/logback-spring.xml

Or via command line:

java -Dlogging.config=classpath:custom/logback-spring.xml -jar app.jar

This is also useful when debugging, because it removes ambiguity about which file Boot should load.

logback-spring.xml Versus logback.xml

This distinction matters more than many people realize.

Use logback-spring.xml when you want Spring Boot-specific features such as:

• 'springProfile'
• 'springProperty'
• Boot-provided include resources

For example:

1<springProfile name="dev">
2    <root level="DEBUG">
3        <appender-ref ref="CONSOLE" />
4    </root>
5</springProfile>

If you put Spring-specific tags into logback.xml, Logback may load the file too early and fail because Boot has not had a chance to apply its extensions.

Do Not Combine Spring Extensions with Logback Scanning

Another subtle issue is Logback configuration scanning. If you enable Logback's own scanning and also use Spring Boot Logback extensions, you can get confusing errors or behavior that looks like the file is not being loaded correctly.

In practice, if you are using logback-spring.xml, let Spring Boot manage that flow rather than layering in conflicting Logback scanning behavior.

Dependency Conflicts Matter

Spring Boot defaults to Logback when you use the standard starters, but if another logging stack is present, Boot may not be using Logback at all.

Check your dependencies for things such as:

• 'spring-boot-starter-log4j2'
• explicit Log4j bridges or exclusions
• accidental removal of spring-boot-starter-logging

If Logback is not the active backend, then logback-spring.xml cannot possibly control logging.

A Practical Debug Checklist

When the file seems ignored, check these in order:

1. Is logback-spring.xml in src/main/resources
2. Is it actually packaged into the runtime artifact
3. Is another logging config file taking precedence
4. Is logging.config pointing somewhere unexpected
5. Is Logback actually the active logging system
6. Does the file use Spring tags that would fail in plain logback.xml

This sequence solves most “Boot does not load my logging file” cases quickly.

Common Pitfalls

One common mistake is placing the file in the source tree but not in the resources directory, which means it never reaches the runtime classpath.

Another issue is editing logback-spring.xml while an older logback.xml or an explicit logging.config property is the file actually being used.

Developers also sometimes use springProfile or springProperty in logback.xml, which loads too early for those extensions to work correctly.

Finally, if Boot is actually using Log4j2 or another backend, no amount of editing Logback XML will change the result. Confirm the active logging system before digging into XML details.

Summary

• Put logback-spring.xml in src/main/resources unless you configure a different location explicitly.
• Prefer logback-spring.xml over logback.xml when you need Spring Boot Logback extensions.
• Check for competing config files and logging.config overrides.
• Make sure Logback is actually the logging system on the classpath.
• Avoid mixing Spring Boot Logback extensions with incompatible early-loading or scanning assumptions.