Log severity levels label how important an event is according to its producer. Common meanings progress from detailed diagnostic events through routine information and warnings to errors and critical failures. The numbers are not portable: syslog uses 0 for its strongest severity and 7 for debug, while Python and .NET use larger numbers for stronger levels; Log4j uses smaller priority numbers for stronger event levels. OpenTelemetry normalizes event severity into ranges from 1 (trace) through 24 (fatal). Compare the meaning of the source level, not its number. RFC 5424, Python logging levels, Microsoft logging levels, Log4j levels, and the OpenTelemetry Logs Data Model define these scales separately.
Severity is an event classification, not an incident priority or a paging instruction. An ERROR may describe one failed request that a client safely retried. A WARNING can reveal a capacity limit that needs planned work. A service can be unavailable without emitting any new log line. Alerting must consider user impact, rate or frequency, ownership, and whether a timely response is possible—not merely the label.
Syslog severity levels: the quick reference
RFC 5424's eight syslog severities are numbered in descending practical severity. The severity number is part of the syslog priority calculation, but a full PRI value also includes the facility. Do not read the full PRI number as the severity without separating those components.
- 0 — Emergency: the system is unusable.
- 1 — Alert: immediate action is required.
- 2 — Critical: critical conditions.
- 3 — Error: error conditions.
- 4 — Warning: warning conditions.
- 5 — Notice: a normal but significant condition.
- 6 — Informational: informational messages.
- 7 — Debug: debug-level messages.
These are the conventional names and meanings listed by RFC 5424, not an automatic mapping to your organization's incident severities; the RFC describes the facility and severity tables as informational. An appliance might label a routine configuration event Alert, or an application might log an actual user-impacting failure as Notice. Validate the producer's behavior before using its syslog level for routing or paging. RFC 5424 itself notes that originators may not use severity with identical intent, so a receiver should preserve the source's original value while applying a documented local interpretation.
If you parse a syslog frame, keep the facility and severity separate. Facility identifies the broad source class; severity expresses the producer's chosen importance. A local4 notice is not “severity 165” simply because its combined PRI equals 165. The RFC's calculation is PRI = facility × 8 + severity, so 165 means facility 20 and severity 5 (Notice). That is a protocol example, not a ranking across applications.
How common application frameworks differ
The names look familiar across systems, but the numeric ordering, available names, and filtering rules differ. A normalized search interface should not compare raw framework numbers as though they shared one scale.
Python logging
Python's standard levels are DEBUG=10, INFO=20, WARNING=30, ERROR=40, and CRITICAL=50. Higher numbers indicate more severe records. Python also defines NOTSET=0, which participates in level configuration and inheritance; it is not a syslog-style emergency event. The Python Logging HOWTO explains that a logger's effective level can prevent lower-level messages from being generated at all.
Use DEBUG for detailed diagnostics, INFO for expected milestones, WARNING for an abnormal condition that the operation can still handle, ERROR when an operation fails, and CRITICAL for a serious failure according to the application's own contract. Those examples are a design convention, not a promise that every library uses the names identically. A Python CRITICAL event is not numerically comparable with syslog 2 or OpenTelemetry 21; any cross-system mapping must use documented meaning.
.NET and ASP.NET Core
The .NET LogLevel enum runs Trace=0, Debug=1, Information=2, Warning=3, Error=4, and Critical=5. Larger event values mean more severe levels. None=6 is a filtering setting that disables logging for a category, not an event more severe than Critical. The ASP.NET Core logging guide describes category and provider filters and says messages below the selected minimum level are not passed to that provider.
This detail matters when a central log search appears to be missing events. If the application or provider threshold is Warning, its Information, Debug, and Trace calls may never reach the collector. A downstream filter cannot recover them. Inspect the active category and provider rules at the source before blaming search or retention. Avoid permanently enabling verbose Trace output merely to diagnose a brief problem; it can be high-volume and include sensitive application data.
Apache Log4j
Log4j's standard event priorities include FATAL=100, ERROR=200, WARN=300, INFO=400, DEBUG=500, and TRACE=600. Smaller priority numbers are more severe, unlike Python and .NET. Log4j's level reference also lists OFF=0 and ALL=Integer.MAX_VALUE, but those are special configuration levels. They must not be treated as emitted events or mapped to syslog Emergency and Debug. A custom Log4j level can have a name and priority chosen by the application, so preserve both before normalization.
OpenTelemetry's normalized severity
The OpenTelemetry Logs Data Model defines optional SeverityText and SeverityNumber fields. SeverityText is the original string from the source. Its normalized numeric ranges are 1–4 TRACE, 5–8 DEBUG, 9–12 INFO, 13–16 WARN, 17–20 ERROR, and 21–24 FATAL. A larger number means stronger severity. 0 may represent unspecified severity; both fields can be absent when the source has no severity concept.
OpenTelemetry intentionally gives each named band four values so a mapping can preserve ordering among multiple source levels with related meanings. For a source with one ERROR level, 17 is the recommended starting value in the error band. Another source's Critical might be a stronger error-band value or a fatal-band value depending on its documented semantics. The mapping is not source number + constant, 100 - source number, or any other universal formula.
The model permits a UI to display a missing severity as informational in some contexts, but that is not permission to silently rewrite the stored event as a genuine source INFO. Keep “unknown or unspecified” distinct in normalization and quality checks unless the application contract gives a defensible default. That distinction matters when severity-based searches or alerts would otherwise miscount unclassified events.
Map by meaning, preserve the source
A practical mapping starts with a source inventory: producer name and version, original level name and numeric value, documented meaning, and examples of events emitted at each level. Then choose a normalized label or OpenTelemetry band for search. Retain the original text and numeric value alongside the normalized result. When the source uses custom levels or vendor-specific language, record the mapping rule and a test event for each branch.
For one event, an application might emit Python ERROR (40) for a failed operation. A documented collector mapping could store its source level as ERROR and 40, and a normalized OpenTelemetry severity as ERROR with SeverityNumber=17. A syslog Error from another source is severity 3 yet can also map semantically to the error band. These are two different source numbers with similar meanings. The resulting normalized value is useful for a cross-source filter, but the retained source fields let an operator audit the translation. This is a conceptual example, not a Fluxtail receiver payload or a claim that a collector maps these fields automatically.
If the source has no level, leave it unspecified and measure how often that occurs. If a parser sees an invalid value, preserve the safe original token, mark the mapping as unclassified, and surface a parsing-quality signal; do not infer importance from the message text with an undocumented rule. A word like “error” inside a successful diagnostic message does not prove an ERROR event. Also avoid collapsing every syslog Notice, application Information, and custom “audit” label into one unreviewed category: they may serve different operational and retention purposes.
The normalization boundary must be tested end to end. Emit a safe, unique marker at each intended source level in a non-production environment; verify what the application actually emits, what the collector receives, what gets stored, and what the search filter returns. Repeat after changes to logger configuration, parser rules, or receiver type. Log normalization covers the broader schema and timestamp questions; severity is just one field in that contract.
Filtering can make lower-level events disappear
An emitter, logger, handler, provider, collector, and backend may each filter events. These stages are not interchangeable:
- Emitter or framework threshold: a call below the effective level may never create a log record. No downstream system can retrieve it later. Python and .NET document this behavior for their level filters. Python Logging HOWTO, ASP.NET Core logging
- Collector or processor filter: the application emitted the record, but the pipeline intentionally drops it before storage. Verify the exact rule, scope, and counters for dropped data. A change to
DEBUGhandling should not accidentally remove required audit or failure evidence. - Search filter: the event is stored, but the current query hides it. Clear severity and time filters, inspect a known marker, and check whether a mapped field exists before concluding that ingestion failed.
Reducing noisy diagnostics can control volume, but do it with an explicit purpose and a way to restore detail safely for a bounded investigation. Do not put credentials, request bodies, session tokens, or sensitive user data into DEBUG merely because it is normally filtered; a later configuration change can expose it. OWASP's logging guidance covers excluding sensitive data and protecting logs throughout their lifecycle.
Severity is not pager urgency
An alert should answer whether a person must act soon, who owns the action, and what evidence supports it. An event's severity is one input. It cannot by itself say how many users are affected, whether retries recovered the operation, whether a deadline is approaching, or whether another system already owns the page. Google SRE's monitoring guidance emphasizes actionable, user-visible symptoms and keeps symptom detection distinct from the search for causes.
For example, one ERROR from an optional dependency could be safely handled by fallback and require no page. A warning that writes are approaching a hard capacity limit may deserve a planned ticket or, if failure is imminent, an urgent action. A service can stop emitting logs during a total outage, so an external check or independent metric is needed for absence. Do not create a rule that pages for every ERROR or assumes no new CRITICAL records means health.
Use a ratio only when numerator and denominator describe the same operation and observation boundary. A count of error-level logs divided by all gateway requests is not automatically a request failure rate: some requests emit several logs, others none, and the pipeline can drop records. Low traffic and missing data need explicit rule behavior. For alert ownership, persistence, deduplication, and testing, see alerting best practices.
Severity helps an investigator narrow records after a symptom appears. Filter by service, environment, release, and a bounded time window first, then inspect the original level, message, and neighboring events. A WARNING before the first user-visible error may be more useful than a flood of later ERRORs. Compare a successful peer and verify the eventual outcome rather than ranking rows by level alone.
Inspect mapped severity in Fluxtail
Fluxtail is a paid Starter/Pro, logs-focused service. Once supported inputs deliver records to named streams, its search and filters and Live Tail can help inspect received events. A severity filter is only as accurate as the source and receiver mapping you verified. Fluxtail cannot recreate events removed by the application or collector, and a log alert should not be mistaken for an external uptime or SLO check.
Built-in AI chat and hosted MCP are separate interfaces for investigating retained data. Hosted MCP uses account-bound OAuth with PKCE; authorized read tools can query logs, while operator mutations require a proposal and short-lived confirmation. Keep the query scoped and check the original rows and source level when an AI summary suggests that an event was urgent. Neither interface sets incident priority by itself.
The rule to remember
Read severity within its source scale, normalize by documented meaning, and preserve the original value. Syslog's 0 is strongest; Python and .NET grow stronger as numbers rise; Log4j's event priorities grow stronger as numbers fall; OpenTelemetry's normalized 1–24 grows stronger as numbers rise. OFF, ALL, None, and NOTSET are not incident severities. The level helps classify a record, but a page still needs evidence of impact and an actionable owner.