Log Levels: TRACE, DEBUG, INFO, WARN, ERROR
Fast recall
Quick revision
Core answer
Logging discipline and understanding of what makes logs useful in production
Logging at INFO or ERROR for everything, creating noise that obscures real problems
Explain the performance cost of low-level logs and how to use parameterized logging safely
Interview-ready guide
Interview answer
Log levels define a contract with whoever is on call — ERROR means a human should look at this now; DEBUG means this is noise in production. Getting levels wrong creates either alarm fatigue or silent failures.
ERROR — requires human attention
- ERROR means something failed that affects user experience or system correctness — a payment failed, a critical integration is down, an unexpected exception escaped all retry logic
- Every ERROR-level log should be actionable — someone should be able to read it and know what happened and where to start investigating; if an ERROR is expected and harmless, it should be WARN
WARN — unexpected but handled
- WARN means something unexpected happened, the system recovered or degraded gracefully, but someone should be aware — a retry succeeded on the third attempt, a downstream service returned a 429 and we backed off, a circuit breaker opened
- WARNs don't require immediate action but should be reviewed in batch; a spike in WARNs often precedes an ERROR
INFO — significant events in normal operation
- INFO marks milestones in normal operation — application started, a request was processed, an order was placed; these provide an audit trail without flooding the log stream
- Log at INFO for: application lifecycle events, significant business events (order placed, payment processed), configuration loaded; avoid logging every HTTP request at INFO in high-volume services (Logback access log handles that separately)
DEBUG — detailed execution flow
- DEBUG is for development and troubleshooting — variable values, branch decisions, loop iterations; never enable globally in production because the volume overwhelms log aggregation systems
- Enable selectively per package:
logging.level.com.myapp.payments=DEBUGtemporarily to diagnose a specific issue; configure with a runtime log level change endpoint (/actuator/loggers) without restarting
TRACE — granular frame-by-frame detail
- TRACE is rarely used in application code; Hibernate uses it to log individual SQL parameter binding, Spring Security uses it for filter chain decisions; useful only for deep framework debugging
Log Levels: TRACE, DEBUG, INFO, WARN, ERROR
Direct Answer
Log levels from least to most severe: TRACE (execution flow detail), DEBUG (diagnostic information), INFO (business events), WARN (recoverable problems), ERROR (failures requiring attention). INFO and above should be useful in production; DEBUG and TRACE are for development troubleshooting.
Deep Dive & Architecture
Observability is a property of a system: the ability to understand its internal state from its external outputs (telemetry) — logs, metrics, and traces.
It exists because modern distributed systems (microservices, containers, cloud) have too many moving parts to inspect directly, and the failure modes are emergent (a slow downstream, a retry storm, a partial outage) rather than a single crashed process.
Log levels from least to most severe: TRACE (execution flow detail), DEBUG (diagnostic information), INFO (business events), WARN (recoverable problems), ERROR (failures requiring attention). INFO and above should be useful in production; DEBUG and TRACE are for development troubleshooting.
Equating observability with 'we have logs' — logs alone can't answer aggregate questions (error rate) or cross-service questions (where is the latency), which metrics and traces provide.
Common Mistakes & Pitfalls
Logging at INFO or ERROR for everything, creating noise that obscures real problems
Check your understanding
Answer these without looking back at the article.
- How do you set up structured logging with SLF4J and Logback in Spring Boot?
- How do you implement structured logging with Logback and include correlation IDs in every log line?
- What is observability and why does it exist? It is the ability to understand a system's internal state from its external outputs — logs, metrics, and traces — so you can debug and run distributed systems you can't inspect directly.
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.