Log Levels Explained: DEBUG, INFO, WARN, ERROR and FATAL.

Log levels exist so you can turn a firehose of messages into something you can search, filter and alert on. Used well, they let you run production at INFO and still find the one ERROR that matters. Used carelessly, every message is "info" and every log search is an archaeology project.

Key takeaways

• Levels rank messages by importance: TRACE < DEBUG < INFO < WARN < ERROR < FATAL.
• Production usually logs INFO and above; DEBUG is switched on temporarily.
• ERROR means something failed that someone should look at - not an expected condition.
• WARN is for "unexpected but handled"; if nobody ever acts on a warning, it's INFO.
• Alert on rates of ERROR/FATAL, not on single lines.

The levels

Names vary slightly between languages and libraries (WARNING vs WARN, CRITICAL vs FATAL), but the order is the same everywhere.

Choosing the right level

Ask who needs to read the message and when:

• Nobody, unless debugging - DEBUG.
• An operator reviewing what happened - INFO.
• Someone, eventually, if it keeps happening - WARN.
• Someone, soon - ERROR.
• Someone, right now, and the service is down - FATAL.

Common mistakes

• Logging expected conditions as ERROR. A user typing a wrong password is not an error in your system; it's INFO (or a security metric).
• Swallowing errors as WARN. If the operation failed and the user saw a failure, it's an ERROR.
• DEBUG in production by default. It multiplies log volume and cost and can leak sensitive data.
• Logging the same error at every layer. Log it once, where it's handled, with full context.

What to include in every line

A level alone isn't enough. Useful lines carry:

• a timestamp with time zone (ideally UTC),
• the level,
• the service or module name,
• a request or correlation ID to tie lines from one request together,
• the message and key fields (user ID, order ID - never passwords or tokens).

2026-10-18T09:14:03.211Z ERROR payments req=7f3c2a order=58114 msg="gateway timeout" duration_ms=10002

Structured (JSON) logs make these fields searchable - see structured logging.

Setting levels per environment

Make the level configurable at runtime (an environment variable or config reload) so you can raise detail for one component during an investigation without a redeploy.

Levels and alerting

Don't page on every ERROR line - one failed request among thousands isn't an incident. Alert on:

• the rate of errors (for example more than 1% of requests in five minutes),
• any FATAL,
• specific errors that always need action (backup failed, certificate renewal failed).

Logs tell you why something broke; external uptime monitoring tells you, independently, that users can't get in - even when the application is too broken to log anything.

Frequently asked questions

• Should I log at INFO or DEBUG in production?

  +

  INFO. Enable DEBUG temporarily, ideally only for the component you are investigating.

• Is WARN useful at all?

  +

  Yes, for conditions that predict trouble - retries, slow dependencies, resources running low. If nobody ever looks at warnings, demote them to INFO or turn them into metrics.

• How long should logs be kept?

  +

  It depends on cost and regulation. A common setup keeps detailed logs for 7-30 days and aggregated metrics for much longer.