Almost every logging system tags each message with a severity. Those labels are called log levels, and they let you keep detailed output while developing, quiet output in production and a way to find the serious entries quickly.
How levels work
Levels are ordered from most detailed to most severe. You set a threshold, and the system records messages at that level and above, discarding the rest. If the threshold is WARN, then DEBUG and INFO messages are dropped and WARN, ERROR and FATAL are written.
The common levels
TRACE: the most fine-grained detail, such as every step inside a function. Rarely enabled outside targeted debugging because of its volume.
DEBUG: information useful to developers diagnosing a problem: variable values, branches taken, queries run. Normally off in production.
INFO: normal, noteworthy events that confirm things are working: service started, job finished, user signed in. A good default for production if volume is reasonable.
WARN (or WARNING): something unexpected or risky happened but the program carried on: a retry, a deprecated feature used, a disk nearing capacity. Worth watching, and may become an error if ignored.
ERROR: an operation failed. The program may continue to run, but something the user or system wanted did not happen: a request failed, a file could not be written.
FATAL or CRITICAL: a severe failure after which the program cannot continue, or a serious condition requiring immediate attention.
Names differ between systems
There is no universal standard, and the names and sets vary:
- Syslog defines eight severities: Emergency, Alert, Critical, Error, Warning, Notice, Informational and Debug, numbered 0 to 7 (0 being the most severe).
- Python's logging module has DEBUG, INFO, WARNING, ERROR and CRITICAL (with numeric values 10 to 50).
- Java logging frameworks such as Log4j and SLF4J-based tools typically use TRACE, DEBUG, INFO, WARN, ERROR and FATAL or similar.
- Windows Event Log uses Information, Warning, Error and, for some sources, Critical and Verbose.
- Browser and Node consoles have log, info, warn, error and debug methods.
When reading an unfamiliar log, find the program's documentation for its level names and order.
Choosing levels as a developer
- Reserve ERROR for failures someone may need to act on. If every expected condition, such as a user typing a wrong password, is logged as an error, the real problems drown.
- Use WARN for recoverable oddities.
- Keep INFO for events that tell the story of normal operation, not every function call.
- Put the detail in DEBUG and TRACE.
- Never log secrets, passwords, tokens or personal data at any level.
Choosing a threshold as an operator
- Production: INFO or WARN, depending on volume and monitoring.
- Staging: INFO or DEBUG.
- Troubleshooting: temporarily lower the threshold (for example to DEBUG) for the affected component, then return it. Debug logging can slow a system and fill disks.
Reading levels in a log file
- Search for ERROR and FATAL to find failures, and WARN for early symptoms. A burst of warnings before an error often reveals the cause.
- Don't ignore repeated WARN messages: repetition is a signal.
- Remember that the level reflects the author's judgement. An ERROR in one program can be routine and a WARN in another can be serious.
Our guides to what a log file is and how to search log files show how to apply this.
Looking at a log
To scan a smaller log by level, open it in Docento's Text & Markdown Editor, type ERROR into Find and step through the matches. For big files, use grep on the command line.
Takeaway
Log levels rank messages from detailed DEBUG to severe FATAL, and a threshold decides which are recorded. Use INFO or WARN in production, raise detail only while troubleshooting and learn the level names of the system you are reading.
