What do the log levels DEBUG, INFO, WARN, ERROR and FATAL mean, and what goes wrong when they are used sloppily?
They rank an entry by how much it demands attention — DEBUG is developer detail, FATAL means the process cannot continue — and using them inconsistently destroys the one filter everyone downstream relies on.
* The severity ladder: each step up widens who must be told, and how fast. *
| Level | Meaning | Who cares |
|---|---|---|
| DEBUG | Internal detail for diagnosing behaviour | Developers, temporarily |
| INFO | Normal, noteworthy operation (service started, job finished) | Operations, retrospectively |
| WARN | Something unusual, but handled — a retry, a deprecated call | Operations, watch the rate |
| ERROR | An operation failed; the system continues | On-call, usually alertable |
| FATAL | The process or service cannot continue | On-call, page immediately |
The levels are the contract between the code that writes a log and every system that reads it: alert rules, retention policies and dashboards all filter on them. Break the contract and the damage is immediate. Log recoverable retries as ERROR and the alerting channel fills with noise until people stop reading it (alert fatigue). Log a real failure as INFO and nobody ever sees it. Leave DEBUG on in production and you pay for the storage, drown the signal, and often leak sensitive values that were only ever meant for a developer's screen.
Tip: the question for choosing a level is not "how interesting is this to me?" but "who should be woken up, and how fast?"
Go deeper:
RFC 5424 — The Syslog Protocol, §6.2.1 severity — the standardised eight-level severity scale (Emergency to Debug) that most loggers map their levels onto.