Log Levels & Severity
Logging & Log Analysis
Chapter 2 · Log Levels & Severity
Chapter 1 established that a log only records what someone chose to record. Severity levels are the mechanism behind that choice — a way of tagging each log line with how much it actually matters, so both the system generating logs and the person reading them can filter signal from noise.
The Standard Levels, Quietest to Loudest
| Level | Meaning | Typical use |
|---|---|---|
| DEBUG | Fine-grained detail, useful only while actively developing or troubleshooting | "Entered function X with these arguments" |
| INFO | Normal, expected events — nothing wrong, just a record that something happened | "User 4821 logged in successfully" |
| WARN / WARNING | Something unexpected, but the system recovered or the request still succeeded | "Retrying database connection (attempt 2 of 3)" |
| ERROR | A specific operation failed — the request or task genuinely did not complete as intended | "Failed to save user preferences: connection timeout" |
| CRITICAL / FATAL | The failure is severe enough to affect the whole system, not just one operation | "Database connection pool exhausted — service unavailable" |
These five names are the most common convention across application-level logging, but they're a convention, not a universal law — some systems use slightly different names or collapse two of these into one. The relative ordering (quietest/least severe to loudest/most severe) is the part that stays consistent.
Why Levels Exist: Filtering Signal From Noise
Almost every logging system lets you configure a minimum level to actually output or store. Set the minimum to WARN, and every DEBUG and INFO line is silently dropped — only warnings and worse get through. This is deliberate: a healthy, correctly-behaving system genuinely doesn't need to permanently store a line for every single normal event, but it does need a way to see everything in detail the moment something is being actively investigated.
WARN and above. This alone often reduces a firehose of thousands of lines down to a handful that are actually worth reading — and if nothing shows up at that filter level for the time window in question, that's itself useful information, pointing you toward Chapter 1's own "silent failure" territory rather than a logged one.
The Real-World Mistake: One Level for Everything
Levels only help if they're used with any discipline. Two genuinely common failure patterns undo the entire benefit:
- Everything logged as INFO (or worse, as ERROR). If routine, expected events are logged at the same level as genuine failures, filtering by level stops working — you're back to reading everything, exactly the noise levels exist to avoid. A classic version of this: logging "user not found" as
ERRORduring a normal login attempt, when a mistyped password is completely routine, not a system failure. - Running with DEBUG enabled permanently in production. Debug-level detail is enormously verbose by design — enabling it around the clock produces massive log volume, real disk and performance overhead, and buries the genuinely important lines even deeper than having no levels at all would.
A Practical Example: The Same Situation, Two Different Levels
Same underlying condition — a database connection that isn't responding — logged at two different levels because the outcome was different. The first line describes something that recovered on its own and needed no action; the second describes an operation that genuinely failed. Reading only the level, before even reading the rest of the message, already tells you which of these two deserves attention right now.
Syslog's Own Scheme: Eight Levels, Not Five
Linux's own system-wide logging convention, syslog, predates most application-level logging frameworks and uses a finer-grained, numbered scale — worth knowing before Chapter 3 covers where these logs actually live.
| Syslog level | Numeric value | Roughly maps to |
|---|---|---|
| Emergency | 0 | System is unusable |
| Alert | 1 | Immediate action required |
| Critical | 2 | CRITICAL / FATAL |
| Error | 3 | ERROR |
| Warning | 4 | WARN |
| Notice | 5 | Normal but significant |
| Informational | 6 | INFO |
| Debug | 7 | DEBUG |
Lower numbers mean higher severity — the opposite direction application-level logging usually reads in, but the same underlying "how much does this matter" idea. You'll see these numeric values directly in real configuration, such as Apache's own LogLevel warn directive or a syslog facility/severity pairing like mail.crit.
Hands-On Exercises
A team logs a mistyped-password login failure as ERROR, arguing "the login did fail, so it's an error." Explain why this chapter would consider that a misuse of the ERROR level, and what level would fit better.
📄 View solutionExplain what "alert fatigue" means, using this chapter's own explanation, and how consistently misusing the ERROR level directly causes it.
📄 View solutionA syslog entry is tagged with severity 2, and another with severity 5. Explain which one is more severe and why, and name the application-level severity name each one roughly corresponds to.
📄 View solutionChapter 2 Quick Reference
- DEBUG → INFO → WARN → ERROR → CRITICAL/FATAL — the standard application-level severity ladder, quietest to loudest
- A configurable minimum level is the first, fastest filter for triage — start at WARN and above
- Common misuse: logging routine events as ERROR, or running DEBUG permanently in production — both destroy the filtering benefit levels exist for
- Alert fatigue is the direct, predictable consequence of level misuse — real errors get ignored once false ones have trained people to stop trusting the signal
- Syslog uses 8 numbered levels (0 Emergency – 7 Debug), lower number = more severe — the opposite direction from how severity usually reads, but the same underlying idea
- Next chapter: Where to Find the Logs