Introduction

In a Spring Boot application, the root logging level controls the default verbosity for loggers that do not have a more specific override. If you want the whole application to be quieter or louder by default, application.yml is the normal place to set it.

The basic configuration is short, but it is worth understanding how root logging interacts with package-specific overrides and environment-based configuration.

Set the Root Level in application.yml

The standard configuration looks like this:

logging:
  level:
    root: INFO

This means:

• 'INFO, WARN, and ERROR messages are shown'
• 'DEBUG and TRACE messages are hidden by default'

Spring Boot passes this through to the underlying logging system, which is Logback by default unless you replace it.

Common Logging Levels

The usual levels are:

• 'TRACE'
• 'DEBUG'
• 'INFO'
• 'WARN'
• 'ERROR'
• 'OFF'

A lower level such as TRACE includes much more detail. A higher level such as ERROR makes logs quieter and more production-oriented.

Override Specific Packages

You do not need to choose one level for everything. A common pattern is a moderate root level plus a more verbose level for your own code.

1logging:
2  level:
3    root: INFO
4    com.example.app: DEBUG
5    org.springframework.web: WARN

In this example:

• most loggers stay at INFO
• your application package becomes more verbose with DEBUG
• Spring Web becomes quieter with WARN

This is often better than setting the entire application to DEBUG just to inspect one part of the code.

Environment Overrides

Spring Boot also lets you override logging levels through environment variables or command-line properties.

For example, on the command line:

java -jar app.jar --logging.level.root=DEBUG

Or with an environment variable:

export LOGGING_LEVEL_ROOT=DEBUG

That is useful for temporary diagnostics in staging or production, because you can increase verbosity without editing the packaged application.yml.

A Practical Default Strategy

A common approach is:

• 'INFO for production root level'
• 'DEBUG only for targeted packages during debugging'
• 'WARN or ERROR for noisy third-party libraries when needed'

That keeps logs useful without flooding storage and alerting systems with low-value detail.

Logging Configuration Still Depends on the Backend

Spring Boot's logging.level.* properties are consistent, but deeper formatting and appenders depend on the actual logging backend. By default that is usually Logback.

So root level is easy to set in application.yml, but things like rolling files, JSON layouts, or custom appenders often live in backend-specific config files such as logback-spring.xml.

A Useful Debugging Workflow

When log output is not what you expect, check in this order:

• the root level in application.yml
• any package-specific overrides
• environment-variable or command-line overrides
• backend-specific config such as logback-spring.xml

That sequence usually finds the real source of the logging behavior faster than changing properties at random.

Common Pitfalls

• Setting root: DEBUG for the whole application when only one package needed extra visibility.
• Forgetting that a package-specific override can make a class noisier or quieter than the root level.
• Assuming changing application.yml is the only way to alter log levels when command-line and environment overrides also exist.
• Confusing Spring Boot logging properties with backend-specific appender or formatting configuration.
• Using overly verbose root levels in production and creating unnecessary logging overhead.

Summary

• Set the default application logging verbosity with logging.level.root in application.yml.
• A common production default is INFO.
• Use package-specific overrides when only part of the code needs more detail.
• Environment variables and command-line flags can override the root level at runtime.
• Root level controls the default baseline, but the logging backend still matters for deeper logging behavior.