Configuring Log Levels Per Package in Java
Fast recall
Quick revision
Core answer
logging.level.=LEVEL , for example logging.level.com.example.orders=DEBUG. The nearest configured ancestor determines the inherited effective level. Spring Boot Actuator can expose runtime logger control when installed and deliberately secured; changes made there are normally temporary and do not survive restart unless configuration is updated.
Interview-ready guide
Interview answer
level prefix.
The strategy is to keep the root logger at a conservative level like INFO, and then raise just the packages you care about. myapp equals DEBUG to get detailed logging only for my own code. The logger name matches the Java package structure, so that line covers every class in that package and its subpackages, and child packages inherit the parent's level unless I override them.
OrderService equals TRACE, for a targeted deep dive. hibernate to WARN, because their DEBUG output is overwhelming. The reason you don't just set root to DEBUG is that it switches on DEBUG for Spring, Hibernate, Tomcat, everything — thousands of lines per request that bury your own logs.
For different environments I'd use Spring profiles, so application-dev has DEBUG and application-prod stays at INFO. The thing that really stands out to interviewers is mentioning Spring Boot Actuator. If Actuator is enabled, you can change a log level at runtime with a POST to the slash actuator slash loggers endpoint — no restart needed.
During a production incident that's genuinely useful: flip a package to DEBUG, reproduce the bug, then flip it back.
Configuring Log Levels Per Package in Java
Direct Answer
Set a package or class logger with logging.level.<name>=LEVEL, for example logging.level.com.example.orders=DEBUG. The nearest configured ancestor determines the inherited effective level. Spring Boot Actuator can expose runtime logger control when installed and deliberately secured; changes made there are normally temporary and do not survive restart unless configuration is updated.
Code Example
# application.properties
# Conservative default for ALL loggers (including libraries)
logging.level.root=INFO
# Your own code, more verbose while investigating
logging.level.com.bookstore=DEBUG
# A single noisy/important class
logging.level.com.bookstore.order.OrderService=TRACE
# Quiet the framework
logging.level.org.springframework.web=WARN
logging.level.org.hibernate.SQL=WARN
Child loggers inherit the parent's level unless overridden, so one package line covers all its subpackages.
Common Mistakes & Pitfalls
- Enabling a broad package: DEBUG on a framework root can create large volume and expose details.
- Expecting a child override to follow its parent: the nearer explicit level wins.
- Assuming runtime changes persist: update durable configuration when the change must survive restart.
- Exposing logger control publicly: the Actuator endpoint is an administrative capability and needs authorization.
- Leaving temporary diagnosis enabled: restore the intended level after collecting evidence.
Check your understanding
Answer these without looking back at the article.
- What is Spring Boot Actuator and what can you do with it?
- How does logback.xml configuration differ from application.properties logging config?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.