skip to content

What are syslog's eight severity levels, and what does a filter for 'Warning and more urgent' actually select?

level: juniorimportance: must knowfreq 45%

answer

  1. eight values in three bits
  2. lower number, louder message
  3. zero is the emergency end
  4. facility says who, not how bad

basics

~10 s

Syslog severities run from 0 Emergency to 7 Debug, and a lower number means a more urgent message. 'Warning and more urgent' therefore selects 0 to 4: Emergency, Alert, Critical, Error and Warning.

solid answer

~40 s

Every syslog message carries one of eight severities: `0` Emergency, `1` Alert, `2` Critical, `3` Error, `4` Warning, `5` Notice, `6` Informational, `7` Debug. The scale runs backwards from intuition: RFC 5424 says a lower numerical severity has a higher practical severity, so 'Warning and more urgent' is the range 0-4, and a rule written as `severity >= 4` selects the noisy end instead. Beside severity sits the **facility** (0-23), which says what kind of source produced the message: kernel, mail, security/authorization, or one of eight local-use codes. Only the numbers travel on the wire; RFC 5424 calls the names "not normative" and warns that severities are subjective, so two devices may grade the same event differently.

go deeper

for a junior

Recite the eight severities from 0 Emergency to 7 Debug and state plainly that a lower number is more urgent. Then turn 'Warning and worse' into the set 0 to 4 without hesitating.

for a middle

Separate facility from severity: the source category from 0 to 23 versus urgency from 0 to 7. Mention that only numbers travel on the wire and that RFC 5424 calls the names non-normative.

for a senior

Show where severity misleads in operations: filters written with the comparison reversed, vendors grading the same event differently, and UDP losing a severity 0 message as silently as a Debug one.

for a principal

Treat severity as an input to policy rather than a fact: decide which severities justify reliable transport or paging, and require per-source review because originators assign the numbers subjectively.

## Where severity lives Every syslog message, whether in the older BSD layout that RFC 3164 described or in the RFC 5424 format that obsoletes it, opens with a **PRI** field in angle brackets. That one number encodes two values: the **facility**, which says what kind of source produced the message, and the **severity**, which says how urgent the originator thinks it is. Turning the number back into the two values is simple arithmetic; this answer is about what the values mean and how an operator uses them. ## The eight severities | Code | Name | RFC 5424 description | |---|---|---| | 0 | Emergency | system is unusable | | 1 | Alert | action must be taken immediately | | 2 | Critical | critical conditions | | 3 | Error | error conditions | | 4 | Warning | warning conditions | | 5 | Notice | normal but significant condition | | 6 | Informational | informational messages | | 7 | Debug | debug-level messages | Three facts about the table matter more than memorising it: - The scale is **inverted**. RFC 5424 section 8.6 states that messages with a lower numerical severity have a higher practical severity. - Only the **number** is on the wire, inside PRI. RFC 5424 section 6.2.1 requires severity values to lie in 0-7 but calls the facility and severity names "not normative"; they are labels for people. - RFC 5424 Appendix A.3 suggests severity 7 for output meant for debugging or testing software and reserving 0 for events such as serious hardware failure or imminent power failure, while allowing an administrator to configure other uses. ## Reading a range filter correctly Operators rarely want one severity; they want "this level and worse". Because the scale is inverted: 1. "Warning and more urgent" is the numeric set 0, 1, 2, 3, 4. 2. A rule written as `severity <= 4` selects exactly that set. 3. A rule written as `severity >= 4` selects Warning, Notice, Informational and Debug: the chattiest end of the scale and the opposite of the intent. Picture a firewall pair during an incident. Get the comparison backwards and the console fills with Informational connection records while the Critical message about a failed interface is filtered out, or the rule meant to shed Debug noise sheds the alerts instead. ## Facility: what kind of source The facility is a number from 0 to 23. The tables in RFC 3164 and RFC 5424 list, among others: - 0 kernel messages, 1 user-level messages, 2 mail system, 3 system daemons - 4 and 10 security/authorization messages; RFC 3164 notes that operating systems used 4, 10, 13 (log audit) and 14 (log alert) for similar purposes - 9 and 15 clock daemon - 16-23, the **local use** facilities local0 to local7 RFC 3164 says a process that has not been assigned a facility may use one of the local-use facilities or user-level. Facility carries no urgency at all: a local0 message can be Emergency or Debug. ## What severity does not promise - **It is the originator's opinion.** RFC 5424 Appendix A.3 warns that severities are very subjective and that a relay or collector should not assume every originator shares one definition. Two firewall models may grade the same link flap as Error and as Notice. - **It is not an application log level.** Application logging frameworks have their own ladder; mapping it onto syslog's eight values is a choice the emitting software makes, and the protocol defines no such mapping. - **It is a drop order under pressure.** RFC 5424 section 8.6 recommends that an originator or relay forced to drop messages drop those of lower severity in favour of higher severity, which only helps when severities were assigned honestly. - **It does not buy reliable delivery.** RFC 5426, the UDP transport, does not prioritise messages by severity on the wire or at the receiver unless the sender, the receiver or the network implements it; a severity 0 datagram is lost as silently as a severity 7 one. ## Syslog beside the other event channel Network devices usually also send SNMP notifications. Syslog is a simplex stream of mostly free text with no acknowledgement in the protocol; among SNMP notifications, an Inform is acknowledged by the notification receiver with a Response and a Trap is not. Which channel carries which event is a device and operator decision, and severity-based filtering is a syslog idea. Whatever the channel, the habit to keep is to read every severity rule as a numeric comparison and check which way it points.

  • If a syslog originator must drop messages under load, which should go first according to RFC 5424?
    RFC 5424 section 8.6 recommends first storing messages until they can be sent; if some must be dropped, drop those of **lower** severity, meaning numerically higher values such as Debug and Informational, in favour of Emergency through Error. It also notes the application may tell a collector or relay that it dropped messages.
  • Can two devices legitimately disagree about whether an event is severity 3 or severity 5?
    Yes. RFC 5424 Appendix A.3 calls severities very subjective and says a relay or collector should not assume all originators share one definition. The protocol fixes only the range 0-7 and the ordering; which number an event gets is the originator's decision, so filters across mixed devices need checking per source.

saying these in an interview costs you the question

  • Severity 7 is the most urgent because it is the highest number.
  • A rule matching severity 4 or higher keeps the urgent messages and drops the noise.
  • The facility value tells you how important a message is.
  • Syslog puts the severity on the wire as a word such as Warning.
  • Every vendor assigns the same severity to the same kind of event.