What Are Logging Levels? TRACE to FATAL Explained

An application is configured to log at WARN. A responder investigating a suspicious login pulls the logs and finds the failed authentications and the privilege error, but nothing about which function called the auth routine, what parameters it passed, or the order of events that led there. That detail existed. The code emitted it at DEBUG and TRACE, and the running config threw it away before it ever reached disk. The investigation is now working from the loudest events only, not the full sequence. That tradeoff, between noise and detail, is exactly what logging levels control.

A logging level is a label attached to each log event that ranks it by severity or importance, from the most routine trace of code execution up to a fatal system failure. The level a system is configured to emit decides which events get written and which are dropped. Set it too high and you lose the context an investigation needs. Set it too low and you drown the signal in volume and cost. This guide covers the standard levels from TRACE to FATAL, how they differ from the RFC 5424 syslog severities a SOC also has to handle, and how to choose a level that serves both operations and detection.

What are logging levels?

A logging level is a severity tag on a log event. When code emits a log line, it emits it at a level (log.error(...), log.debug(...)), and the logging framework compares that level against the configured threshold. Events at or above the threshold are written; events below it are discarded. A system running at INFO writes INFO, WARN, ERROR, and FATAL, and silently drops DEBUG and TRACE.

That single threshold is the entire point. It is a filter that controls verbosity at runtime without touching the code. The same application can run at DEBUG in a test environment to capture everything, then run at INFO or WARN in production to keep volume and storage manageable. The developer instruments the code once, at the right level per event, and operators turn the dial later.

Levels also serve as a triage signal. An ERROR or FATAL event is one a human or an alert rule should look at; an INFO or TRACE event is usually only read after the fact, during an investigation or while building a baseline. That ranking is what makes log analysis tractable: it lets an analyst or a detection rule sort the few events that demand attention from the many that are routine. The levels are most familiar from application logging frameworks (Log4j, Logback, Python logging, Serilog), but the same idea governs operating system logs, network devices, and cloud services.

The standard logging levels, TRACE to FATAL

Most application logging frameworks use a common ladder of levels, ordered here from least to most severe. The exact set varies by framework, but the meanings are consistent.

TRACE is the most verbose level. It captures the execution of code at a fine grain, the path through functions and the values along the way. It is treated as an info-class message that requires no action; it exists to reconstruct exactly what the program did.

DEBUG captures detail useful while debugging or troubleshooting. It is a step less granular than TRACE and is the level engineers turn on in a test environment to see what an application is actually doing.

INFO records that an event happened without implying anything is wrong. A service started, a job completed, a user logged in. These are the routine entries that document normal operation, and in everyday running they can usually be ignored.

WARN flags an unexpected event that may disrupt or delay other processes but has not broken anything yet. It is the "look at this before it becomes a problem" level: a retry, a deprecated call, a resource running low.

ERROR means a component is inoperable and is interfering with other functionality. Something failed and the failure has consequences. Errors generally warrant attention because functionality is already degraded.

FATAL is the most severe level. At least one component has failed in a way that causes a fatal error in the larger system. It is the level that should page someone.

Beyond the named levels, frameworks usually offer two catch-all settings for the threshold itself: ALL, which logs every level, and OFF, which logs nothing. And because the scheme is a convention rather than a law, organizations can define custom levels for their own needs, though staying close to the standard ladder keeps logs portable and tools interoperable.

Logging levels vs. syslog severities

Here is the trap for anyone working across systems: the TRACE-to-FATAL ladder above is the application-framework convention, and it is not the same scheme as the syslog severity levels that operating systems, network gear, and many appliances emit. A SOC ingests both, and they do not line up cleanly.

Syslog severities are defined by RFC 5424. There are eight of them, numbered 0 through 7, and the numbering runs the opposite direction from intuition: the lowest number is the most severe.

Three things follow from this. First, the schemes have different granularity at the top: syslog splits the severe end into Emergency, Alert, and Critical, where the application ladder has only FATAL. Second, syslog has no TRACE; its most verbose level is Debug (7). Third, and most error-prone, the direction is inverted. In syslog a lower number is worse (0 is the most severe), while in the application ladder a "higher" level is worse. A rule written as "alert on severity greater than 4" means the opposite thing in each scheme.

This matters the moment logs from different sources land in one place. A security information and event management platform ingesting both application logs and syslog has to normalize the two scales before a severity-based detection rule can span them. Get the mapping wrong and a rule either floods the analyst with debug noise or silently ignores critical events. Knowing that "ERROR" in an app log and "Error (3)" in syslog are close but the surrounding scales differ is a small piece of knowledge that prevents a large class of detection mistakes.

Why logging levels matter for detection and response

Logging levels are usually framed as a developer's verbosity control. For a defender they are also a detection and forensics control, and the level a system runs at directly shapes what the SOC can see.

The level sets the ceiling on evidence. An investigation can only use what was written. If an application runs at WARN, the DEBUG and TRACE detail that would show the exact sequence of a compromise was never recorded, no matter how good the responder is. The running level is a decision, made in advance, about how much of an incident will be reconstructable.

Levels drive alerting and triage. Detection rules and on-call pages are commonly keyed to severity: page on FATAL, ticket on ERROR, ignore INFO. That makes levels a filter against alert fatigue, the same reason they exist for developers. It also makes them a liability if instrumented carelessly: an event logged at INFO that should be ERROR will not fire the rule that was supposed to catch it, and a flood of events logged too high will bury the real one.

Verbosity trades against volume and cost. Logging at DEBUG everywhere in production produces enormous volume, which raises storage and indexing cost and can slow the very searches an analyst runs during an incident. Logging too sparingly saves money and loses the evidence. The level is where that tradeoff is set, which is why production systems typically run at INFO or WARN and raise verbosity deliberately when troubleshooting.

Attackers target the logs. An adversary who can lower an application's logging level, or disable logging, blinds the defender without touching anything else. Logging configuration is part of the attack surface, and a sudden drop in log verbosity or volume is itself worth alerting on.

Choosing a logging level

There is no single right level for every system. The level is chosen per environment and per source, balancing evidence against volume.

Run production at INFO or WARN, not DEBUG. Production systems should log enough to document normal operation and flag problems (INFO or WARN) without the volume and cost of full DEBUG. Reserve DEBUG and TRACE for test environments or for short, deliberate windows when actively troubleshooting a specific issue.

Raise verbosity deliberately, then lower it again. When chasing a bug or scoping an incident, temporarily raising a component to DEBUG can surface the detail you need. Treat it as a temporary change, because left on, it generates volume and cost indefinitely and can itself become noise.

Instrument events at the right level in code. A level is only useful if developers emit events at the correct severity: a real failure at ERROR or FATAL, a recoverable oddity at WARN, routine activity at INFO. Mislabeled events break both alerting and investigation. This is a detection-engineering concern as much as a development one.

Keep security-relevant logging high enough. Authentication, authorization, and audit events should be logged at a level that guarantees they are retained, not buried below the production threshold. The events a responder will need are often not the ones that look urgent at runtime.

Normalize across schemes before alerting. Where application levels and syslog severities both feed a central store, map them to one common scale first so that severity-based rules behave consistently. This is a standard step when feeding centralized logging and is where the inverted syslog numbering bites teams that skip it.

Frequently Asked Questions

What are logging levels?

Logging levels are severity labels attached to log events that rank them by importance, from the most verbose (TRACE) to the most severe (FATAL). A system is configured with a threshold level, and it writes every event at or above that threshold while discarding the rest. This lets operators control how much detail a system records at runtime without changing the code, and lets analysts and alert rules sort urgent events from routine ones.

What are the standard logging levels in order?

From least to most severe, the common application logging levels are TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. TRACE and DEBUG capture fine-grained execution and troubleshooting detail, INFO records routine events, WARN flags something unexpected that has not yet failed, ERROR marks a component that is inoperable and affecting others, and FATAL marks a failure that breaks the larger system. Frameworks also offer ALL and OFF as catch-all threshold settings.

What is the difference between logging levels and syslog severities?

The TRACE-to-FATAL ladder is the application logging framework convention. Syslog severities, defined in RFC 5424, are a separate scheme of eight levels numbered 0 to 7: Emergency, Alert, Critical, Error, Warning, Notice, Informational, and Debug. The schemes differ in granularity (syslog splits the severe end into three levels and has no TRACE) and, critically, in direction: in syslog a lower number is more severe, the opposite of the application ladder. A SOC ingesting both must normalize them before applying severity-based rules.

Which logging level should production use?

Production systems should generally run at INFO or WARN. That records normal operation and flags problems without the volume, storage cost, and performance impact of logging everything at DEBUG. DEBUG and TRACE are best reserved for test environments or short, deliberate troubleshooting windows, then turned back down.

Why do logging levels matter for security?

The level a system runs at sets the ceiling on what an investigation can reconstruct, because a responder can only use events that were actually written. Levels also drive alerting, so a security event logged at too low a severity may never fire the rule meant to catch it. Security-relevant logs such as authentication and audit events should be kept at a level high enough to guarantee they are retained, and a sudden drop in log verbosity can itself signal an attacker tampering with logging.

Can you create custom logging levels?

Yes. Logging levels are a convention, not a fixed standard, and most frameworks allow custom levels for specific needs. The tradeoff is portability: staying close to the standard TRACE-to-FATAL ladder keeps logs readable across teams and interoperable with tools that expect the common levels, while custom levels require every consumer of the log to understand them.

The bottom line

A logging level ranks each log event by severity, from TRACE, the fine-grained trace of code execution, up through DEBUG, INFO, WARN, and ERROR to FATAL, a failure that breaks the system. The configured level acts as a filter: events at or above it are written, the rest are dropped, which lets operators trade detail against volume at runtime without changing code. The application ladder is not the same as the RFC 5424 syslog severities, which number eight levels from 0 to 7 with the direction inverted, and a SOC that ingests both has to normalize them before any severity rule can span them.

For a defender, the level is not just a developer setting. It is the ceiling on the evidence an investigation will have, the filter that decides which events page someone, and a piece of attack surface an adversary may try to lower. Run production at INFO or WARN, raise verbosity deliberately and briefly when troubleshooting, instrument events at the right severity, keep security logging high enough to survive, and normalize levels across schemes before alerting. Do that, and the responder pulling logs after the next incident finds the full sequence, not just the loudest events.