Introduction

Spring Boot can expose the active profile to Logback, but only when Logback is loaded through Spring-aware configuration. The key is to use logback-spring.xml instead of logback.xml, then pull values from the Spring environment with springProperty or conditionally configure appenders with springProfile.

Use logback-spring.xml

This is the first requirement. If your file is named logback.xml, Spring Boot's extra Logback tags are not available.

A minimal setup looks like this:

1<?xml version="1.0" encoding="UTF-8"?>
2<configuration>
3  <springProperty scope="context"
4                  name="activeProfile"
5                  source="spring.profiles.active"
6                  defaultValue="default" />
7
8  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
9    <encoder>
10      <pattern>%d %-5level [%property{activeProfile}] %logger - %msg%n</pattern>
11    </encoder>
12  </appender>
13
14  <root level="INFO">
15    <appender-ref ref="CONSOLE" />
16  </root>
17</configuration>

That puts the active profile into each log line.

Without the -spring filename, the springProperty tag will not be understood by the Logback parser.

Where The Profile Comes From

The property value can be supplied through any standard Spring environment source:

• 'application.properties'
• 'application.yml'
• environment variables
• command-line arguments

For example:

spring.profiles.active=dev

Or:

java -jar app.jar --spring.profiles.active=prod

Spring Boot resolves the environment and then makes those values available to the Spring-aware Logback configuration.

That means you do not need custom bootstrap code just to copy profile data into the logger configuration.

If more than one profile is active, Spring still exposes the active profile state through the environment bridge, and Logback can consume the resulting value in exactly the same way. That is much more reliable than manually trying to inspect startup arguments inside custom logging bootstrap code.

Use springProfile For Profile-Specific Logging

Sometimes you do not just want to print the profile. You want different logging behavior depending on it:

1<?xml version="1.0" encoding="UTF-8"?>
2<configuration>
3  <springProfile name="dev">
4    <root level="DEBUG">
5      <appender-ref ref="CONSOLE" />
6    </root>
7  </springProfile>
8
9  <springProfile name="prod">
10    <root level="INFO">
11      <appender-ref ref="JSON" />
12    </root>
13  </springProfile>
14</configuration>

This is often cleaner than scattering profile-dependent logging logic across Java configuration classes.

springProfile is especially useful when development should log verbosely while production should emit JSON or structured logs with stricter levels.

Inject Other Spring Properties Too

The same mechanism works for more than profiles:

1<springProperty scope="context"
2                name="appName"
3                source="spring.application.name"
4                defaultValue="demo-app" />

That makes Logback configuration line up nicely with the rest of the Spring environment model.

If you already trust Spring configuration for ports, database URLs, and service names, it makes sense to let logging pull from the same place.

This also helps keep profile-sensitive logging decisions in one configuration file instead of splitting them across Java code, environment scripts, and logger XML fragments. Centralizing the logic makes later troubleshooting much easier when logging behavior differs between development, staging, and production.

It also reduces the chance that logging and application profile selection drift apart over time.

That consistency matters during incident response.

It keeps diagnostics aligned with runtime configuration.

That helps support teams too.

Common Pitfalls

One common mistake is naming the file logback.xml and then wondering why springProperty or springProfile does not work.

Another issue is assuming spring.profiles.active is always defined and not providing a default value for logging startup.

A third problem is trying to inject the active profile via custom Java code after logging has already initialized.

Finally, teams sometimes over-engineer this by writing custom profile bridges when Spring Boot already provides the integration directly.

Summary

• Use logback-spring.xml, not logback.xml, when you want Spring-aware Logback features.
• Use springProperty to expose spring.profiles.active as a Logback property.
• Use springProfile for profile-specific appenders or log levels.
• Provide default values so logging still starts cleanly when no profile is set.
• Keep the integration in Logback configuration instead of recreating it in application code.
• Test startup with and without an active profile so logging defaults stay safe.