Configuring Log Levels in Spring Boot

Direct Answer

Set levels with logging.level.<logger-name>=LEVEL in Spring Boot configuration, for example logging.level.com.example.orders=DEBUG. Child loggers inherit an effective level unless overridden. The Actuator loggers endpoint can inspect or change levels at runtime when the actuator is present and the endpoint is deliberately exposed and secured; runtime changes may not survive restart.

Deep Dive & Architecture

Spring Boot maps logging.level.<name> to the selected logging system. The name can be the root logger, a package, or a class. For example, logging.level.com.example.orders=DEBUG affects that package hierarchy unless a child has its own setting.

Choose the root and package levels for each environment instead of treating INFO as a universal rule. Production may keep noisy framework packages at WARN while leaving application business events at INFO; a temporary diagnosis may enable DEBUG for one narrow logger.

With Actuator installed, the loggers endpoint can show effective levels and accept runtime changes. It is not exposed automatically in every deployment, should be protected as an operational control, and an in-memory change generally disappears when the application restarts.

Code Example

# application.properties
logging.level.root=INFO
logging.level.com.bookstore=DEBUG
logging.level.com.bookstore.order.OrderService=TRACE
logging.level.org.hibernate.SQL=WARN

# application-prod.yml — quieter in production
logging:
  level:
    root: WARN
    com.bookstore: INFO

Common Mistakes & Pitfalls

• root=DEBUG: enables DEBUG for every dependency; logs become unreadable.
• Leaving DEBUG in prod: hurts performance and storage; revert after troubleshooting.
• No profiles: one file for all environments forces manual edits per deploy.