A log level is a severity label attached to every log message that indicates how important the event is, such as DEBUG, INFO, WARNING or ERROR. In monitoring & logs on servers, log levels serve two purposes: they let a reader or a tool filter messages by importance, and they let an application decide at runtime which messages to record at all, by setting a threshold below which messages are discarded.
Log levels are defined both by logging libraries inside applications and by system facilities such as Syslog, whose eight severities are standardized in RFC 5424. A consistent use of levels is what turns a stream of text into a signal that alerting, log aggregation and incident analysis can rely on.
How log levels filter messages
Each logger has a configured threshold. When the code emits a message, the library compares the message level with the threshold: messages at or above the threshold are passed to the output, and messages below it are dropped, ideally before the message text is even built. Setting the threshold to WARN therefore records warnings, errors and fatal events but suppresses INFO and DEBUG output.
Thresholds can usually be set per logger or per module, so an operator can turn on DEBUG output for one noisy component while keeping the rest of the application at INFO. Many frameworks also allow changing the level without a restart, through a configuration reload, an admin endpoint or an environment variable, which is invaluable during an incident.
Downstream systems apply their own filters as well. A log shipper may forward only WARN and above to a central store to save cost, and an alerting rule may page on-call engineers only for ERROR or CRITICAL events. The level is therefore a contract between developers and operators about what each message means.
Standard log levels and their meaning
Names vary between ecosystems, but most libraries use a common ladder of severities. The table below shows the usual levels from least to most severe, with guidance on what belongs at each one.
| Level | Meaning | Typical example | Enabled in production |
|---|---|---|---|
| TRACE | Very detailed internal flow | Entering and leaving functions | Almost never |
| DEBUG | Diagnostic detail for developers | Query parameters, cache decisions | Only temporarily |
| INFO | Normal, noteworthy events | Service started, job completed | Usually yes |
| WARN | Unexpected but handled situation | Retry succeeded, deprecated setting used | Yes |
| ERROR | Operation failed | Request could not be processed | Yes, often alerted |
| FATAL or CRITICAL | Process or service cannot continue | Database unreachable at startup | Yes, always alerted |
The essential rule is that ERROR should mean that something actually failed and may need human attention. When handled, expected conditions such as a user entering a wrong password are logged as ERROR, the level loses its meaning and alerts become noise.
Syslog severities compared with application levels
System logs on Unix and Linux servers use the eight Syslog severities, numbered 0 to 7, where a lower number means higher severity. Tools such as journalctl -p err and rsyslog filters work with these values, so applications that forward logs to Syslog must map their own levels onto this scale.
| Syslog value | Syslog name | Usual application level |
|---|---|---|
| 0 | Emergency | Not used by single applications |
| 1 | Alert | FATAL in some mappings |
| 2 | Critical | FATAL or CRITICAL |
| 3 | Error | ERROR |
| 4 | Warning | WARN |
| 5 | Notice | INFO for significant events |
| 6 | Informational | INFO |
| 7 | Debug | DEBUG and TRACE |
Web servers follow the same idea in their error log configuration. Nginx, for example, accepts error_log /var/log/nginx/error.log warn;, which records warnings and everything more severe. The access log is different: it records every request regardless of severity, so log levels do not apply to it in the same way.
Choosing the right level in practice
Choosing levels well requires thinking about who will read the message and what they should do. The decision table below gives practical guidance for both developers writing messages and operators setting thresholds.
| Situation | Recommended choice | Reason |
|---|---|---|
| Normal production operation | Threshold at INFO | Enough context without excessive volume |
| High-traffic service with costly storage | Threshold at WARN, sampled INFO | Controls ingestion and retention costs |
| Active incident investigation | DEBUG for the affected module only | Detail where needed, temporary and targeted |
| Invalid input from a client | INFO or WARN, not ERROR | The service behaved correctly |
| Dependency failed after all retries | ERROR with context fields | Requires attention and correlation |
In structured logging, the level is a separate field, for example "level": "error", rather than a word inside the text. This makes filtering in an ELK stack, Splunk or similar tools fast and reliable, because queries match a field instead of parsing free text.
Common mistakes with log levels
Poor level discipline is one of the most common reasons why logs are large but unhelpful. These mistakes appear again and again.
- Leaving DEBUG enabled in production, which fills disks, raises costs and may write passwords or personal data into logs.
- Logging handled conditions as ERROR, which trains people to ignore error counts and hides real failures.
- Logging the same failure at every layer, producing several ERROR entries for one event; log it once, where it is handled.
- Inconsistent levels across services, which breaks central alerting rules based on severity.
- Building expensive messages before the level check, which costs CPU even when the message is discarded.
- No log rotation, so even a sensible level eventually fills the disk.
The short version
A log level is a tag that says how serious a message is. Programs write notes about what they are doing. Some notes are routine, some are warnings, and some report real failures.
The level works like the priority on hospital calls. Routine updates are noted quietly, while an emergency sets off an alarm right away. Administrators choose which levels to keep, so they see the important notes without drowning in details.
Where it makes a difference
An e-commerce API produces about 50 GB of logs per day because a previous release left most services at DEBUG. Storage costs climb, searches in the central log platform become slow, and the on-call team receives alerts for hundreds of ERROR entries that turn out to be rejected coupon codes.
The team sets the production threshold to INFO, reclassifies invalid customer input as INFO, and keeps ERROR for failed payments and unreachable dependencies. An admin endpoint now lets engineers raise one module to DEBUG for 30 minutes during an incident. Daily log volume falls to about 6 GB, alert noise disappears, and real payment failures now stand out within minutes.