Log Level Hierarchy in Java
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The log level hierarchy works inclusively, not exclusively.
When you set a logger to INFO, you're not saying show me only INFO messages — you're saying show me INFO and everything more severe than INFO. So INFO, WARN, and ERROR all appear, while DEBUG and TRACE get filtered out. The five levels from least to most severe are TRACE, DEBUG, INFO, WARN, and ERROR.
Think of the configured level as a minimum threshold: everything at that level or higher in severity passes through. So if you set WARN, you only see WARN and ERROR. If you set ERROR, you only see ERROR.
And if you set DEBUG, you see everything except TRACE. This is what makes logging configuration so flexible — you control verbosity with a single setting and no code change. The hierarchy also applies to loggers themselves, through your package structure.
payment, that subpackage inherits INFO from its parent. payment to DEBUG, that explicit setting wins for just that package. Two mistakes freshers make: first, thinking INFO literally means only INFO, then being confused when WARN and ERROR still show up.
Second, getting the direction backwards — ERROR is more severe than DEBUG, so setting ERROR gives you fewer messages, not more. One more practical note: use parameterized logging with curly-brace placeholders, so that even the suppressed debug statements don't waste time building strings that never get printed.
Log Level Hierarchy in Java
Direct Answer
The log level hierarchy is inclusive: the configured level is a minimum threshold, so it shows that level and everything more severe. Setting INFO shows INFO, WARN, and ERROR while suppressing DEBUG and TRACE. Loggers also inherit: a child package logger uses its parent's level unless explicitly overridden.
Deep Dive & Architecture
Log incoming HTTP requests at INFO in production — a concise summary (method, path, status, duration) as an audit trail — and at DEBUG during development for headers, params, and bodies.
Never log at ERROR for normal traffic, and never log sensitive data (auth tokens, passwords, card numbers) at any level.
Spring Boot offers built-in request logging, but a custom filter gives you precise control.
System.out.println has no log levels (can't filter), no timestamps (can't correlate), no logger name/context, no per-environment configuration, and writes to stdout which may not be captured in production. A logging framework like SLF4J + Logback (the Spring Boot default) gives all of that for the same effort — log.info(...) instead of System.out.println(...).
Code Example
log.trace("entry: registerCustomer({})", email); // shown only at TRACE
log.debug("validating email {}", email); // shown at DEBUG and below threshold
log.info("registering customer {}", email); // shown at INFO, WARN... no, at INFO threshold
log.warn("duplicate attempt for {}", email); // shown at INFO and WARN thresholds
log.error("failed to save {}", email); // shown at every threshold up to ERROR
# logging.level.com.example=INFO
# -> trace + debug are suppressed
# -> info, warn, error all print
Nothing in the code changes; only the configured threshold decides what reaches the output.
Common Mistakes & Pitfalls
- Exclusive thinking: expecting INFO to show only INFO, then being confused that WARN/ERROR still appear.
- Inheritance surprise: assuming setting
com.appto DEBUG also lowerscom.app.subwhen that subpackage is explicitly set to INFO — explicit settings win. - Backwards severity: thinking ERROR is the most verbose; it's the least.
Check your understanding
Answer these without looking back at the article.
- How do you decide which log level to use when adding a log statement in Java?
- How do you configure different log levels for different packages in a Java application?
- What log level would you use to log an incoming HTTP request in a Spring Boot application?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.