What Are Log Levels?

Last verified on Nov 8, 2026.

A log level is a label on each log message that says how severe it is. You use it to decide which messages to keep, which to alert on, and which to ignore. Most systems offer five or six names, from DEBUG at the detailed end to ERROR or CRITICAL at the serious end, but the numbers behind those names differ between systems.

The Standard Levels

Python's logging module is a good reference because it documents both the meaning and the number of each level.

The default level is WARNING, so a fresh Python program drops DEBUG and INFO until you configure it otherwise.

How Level Filtering Works

A logger compares its own level with the level of each call. If the logger's level is higher than the call's, no message is generated. That is the basic mechanism that controls how noisy your output is.

import logging

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(name)s %(message)s")
log = logging.getLogger("checkout")

log.debug("cart loaded")          # dropped: 10 is below INFO (20)
log.info("payment started")
log.warning("retrying card processor")
log.error("payment failed")

Running this prints three lines and no DEBUG line:

INFO checkout payment started
WARNING checkout retrying card processor
ERROR checkout payment failed

Syslog and OpenTelemetry Scales

Syslog defines eight severities in RFC 5424: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, and 7 Debug. A lower number is a higher practical severity.

The OpenTelemetry log data model goes the other way. Its SeverityNumber is 1 to 24, and larger means more severe. The ranges are TRACE 1-4, DEBUG 5-8, INFO 9-12, WARN 13-16, ERROR 17-20, and FATAL 21-24. A SeverityNumber of 17 or higher marks an erroneous event.

OpenTelemetry's appendix shows how existing formats line up:

When a record has no severity at all, the data model says a backend may treat it as INFO (9). That is why a missing level can hide a real error, so set one on every record.

Choosing a Level

• Use ERROR when an operation failed and someone may need to act. A burst of identical ERROR lines before each restart is the footprint of crash loops, and an ERROR message you have never seen before is what novel event detection looks for. Use WARNING when it succeeded in a degraded way, such as a retry that worked.
• Keep INFO for events you would want in a timeline: a deploy, a job start, a payment completed.
• Keep DEBUG off in production by default, and turn it on per component when you need it. For volume control, see log sampling.
• Do not encode meaning in the level that a field should carry. NIST notes that some generators assign severity values to denote message classes rather than real severity, which makes analysis harder.

For a longer checklist, see logging best practices and the Python logging guide. Levels work best next to structured fields such as a trace ID.

Levels in Sazabi

Sazabi, an AI-native observability and security platform, takes levels as they arrive. Its Vector setup copies the level or severity field into the OTLP severityText, so the level you set at the source is the one you search on. See Vector and log search.