Introduction

Spring Boot manages Logback through its dependency-management layer, so changing the version is usually a dependency-override task rather than a direct logging-configuration task. The important part is to override the managed version cleanly without breaking the compatibility assumptions Spring Boot makes for the rest of the logging stack.

How Spring Boot Chooses the Version

When you depend on spring-boot-starter or spring-boot-starter-web, Boot pulls in spring-boot-starter-logging. That starter brings Logback and related logging libraries using versions defined by the Spring Boot BOM.

That means adding logback-classic again with a different version is not always the cleanest answer. Often the better approach is to override the managed version property or dependency-management entry.

Maven Override

In Maven, inspect the effective dependency tree first so you know what version is currently selected.

mvn dependency:tree | grep logback

Then override the version explicitly in dependencyManagement or with the property Spring Boot uses in your chosen release line.

A direct dependency-management override is clear and predictable:

1<dependencyManagement>
2  <dependencies>
3    <dependency>
4      <groupId>ch.qos.logback</groupId>
5      <artifactId>logback-classic</artifactId>
6      <version>1.5.18</version>
7    </dependency>
8    <dependency>
9      <groupId>ch.qos.logback</groupId>
10      <artifactId>logback-core</artifactId>
11      <version>1.5.18</version>
12    </dependency>
13  </dependencies>
14</dependencyManagement>

If your build already imports the Spring Boot BOM, this override takes precedence for those artifacts.

Gradle Override

In Gradle, start the same way by checking resolution output.

./gradlew dependencies --configuration runtimeClasspath

Then declare the version you want in the dependency-resolution layer.

1dependencies {
2    implementation("org.springframework.boot:spring-boot-starter-web")
3    implementation("ch.qos.logback:logback-classic:1.5.18")
4    implementation("ch.qos.logback:logback-core:1.5.18")
5}

If another managed version still wins, enforce the version through constraints or a resolution strategy rather than adding duplicate declarations blindly.

Verify Compatibility Before Forcing an Upgrade

This is the part teams skip. Spring Boot manages versions as a tested set, not as random pins. If you move Logback far ahead of the Boot release line, you may also need compatible versions of slf4j-api and related bridges.

So the safe workflow is:

1. Check the current resolved version.
2. Override Logback in one place.
3. Re-run the dependency report.
4. Start the application and verify logging initialization.
5. Run tests that touch bootstrap logging and custom appenders.

When You Might Exclude Boot Logging

If you are replacing Logback entirely, for example with Log4j 2, you would exclude spring-boot-starter-logging. That is a different operation from merely changing the Logback version. Do not exclude Boot logging unless you actually intend to swap logging frameworks.

Use the Smallest Override That Solves the Problem

If you only need a patched Logback release for a bug fix or security reason, keep the override as narrow as possible. Overriding logback-classic and logback-core is usually enough. Replacing large chunks of Boot dependency management makes later framework upgrades harder because you stop benefiting from the platform defaults.

After the override, check startup logs and any custom appenders, encoders, or rolling-policy settings. Logging problems often appear early in application bootstrap, so they are easy to catch if you test immediately after the dependency change instead of discovering them later in production.

Common Pitfalls

• Adding a new logback-classic dependency without checking whether Boot still resolves the old managed version elsewhere.
• Upgrading Logback without verifying compatibility with the Boot release line and slf4j versions.
• Confusing Logback version changes with edits to logback-spring.xml. Configuration and dependency resolution are separate concerns.
• Excluding spring-boot-starter-logging when the goal was only to bump the version.
• Failing to inspect the dependency tree before and after the override.

Summary

• Spring Boot manages Logback through its BOM and starter dependencies.
• Change the version by overriding dependency management, not by guessing at logging config files.
• Verify the resolved version with Maven or Gradle before and after the change.
• Keep compatibility with the rest of the logging stack in mind.
• Exclude Boot logging only when you are replacing the framework, not when you are upgrading it.