Log Levels: When to Use DEBUG, INFO, WARN, ERROR

Log levels are a severity ranking attached to every log line — DEBUG, INFO, WARN, ERROR, and sometimes TRACE or FATAL above and below them — that lets you control how much detail is emitted and how urgently a line deserves attention. Almost every logging framework supports them, but teams routinely misuse them: overusing ERROR for expected conditions, leaving DEBUG on in production, or logging at INFO what should be DEBUG. The levels only earn their keep if they’re used consistently.

What each level means

• DEBUG. Fine-grained, developer-facing detail useful for diagnosing a specific problem — variable values, branch decisions, individual step timing. Too verbose and too high-volume for production defaults; typically off unless actively investigating something.
• INFO. Notable events in the normal operation of the system — a service started, a job completed, a request was handled. Should be sparse enough that a human can skim a service’s INFO stream and understand what it’s doing, not so dense it becomes noise.
• WARN. Something unexpected or degraded happened, but the system recovered or continued — a retry succeeded, a fallback was used, a deprecated code path was hit. Warrants attention over time but not an immediate page.
• ERROR. An operation failed and could not recover on its own — a request that returned a 500, a database write that was lost, an unhandled exception. Reserve this for genuine failures; using it for expected, handled conditions (like a normal 404 or validation failure) trains responders to ignore it.
• FATAL/CRITICAL (where supported). The process cannot continue and is about to exit or crash — rare, and usually accompanied by an actual process termination.

Rules of thumb

• Ask “who needs to see this, and how urgently?” DEBUG is for the engineer actively debugging right now, INFO is for anyone reconstructing what happened later, WARN is for someone reviewing trends, and ERROR is for someone who should probably act.
• An expected, handled failure is not an ERROR. A user submitting an invalid form, a cache miss, a client hanging up mid-request — these are normal system behavior and belong at INFO or WARN. Reserving ERROR for genuine, unexpected failures keeps error-rate dashboards and alerts meaningful.
• Default production verbosity should be INFO or WARN, not DEBUG. Verbose default levels increase log volume — and therefore ingestion and storage cost — roughly linearly with traffic, often for detail nobody reads unless there’s an active incident.
• Levels should be consistent across a codebase, not per-developer taste. Without a shared convention, one team’s WARN is another team’s INFO, and cross-service log queries and alerting rules become unreliable.

Dynamic log levels and the cost trade-off

Most modern logging frameworks (Java’s Logback and Log4j2, Spring Boot’s Actuator, many Go and Node logging libraries) support changing the active log level at runtime — per package, per service instance, or globally — without a redeploy. This is valuable during an active incident: temporarily raising a specific component to DEBUG gives detailed visibility exactly when it’s needed, then it can be turned back down once the investigation is done.

This matters because the alternative — leaving DEBUG on permanently “just in case” — has a real cost. Verbose logging multiplies ingestion volume into backends like Elasticsearch or Loki, which drives up both storage cost and query latency, and it makes ERROR and WARN lines harder to find in the noise during an actual incident. The practical pattern is: run at INFO/WARN by default, instrument dynamic level control (a protected admin endpoint, a config flag, or a feature-flag-driven override) so specific components can be turned up temporarily, and treat “why is DEBUG on in prod” as something worth noticing rather than ignoring. Some backends also support ingest-time or query-time sampling of high-volume DEBUG/INFO lines as a middle ground between “log everything” and “log nothing,” discussed further in the logs hub’s retention and cost material.