Syslog severity levels

Contract

Every log event is assigned exactly one of eight severities, chosen from the condition the event represents, and written as the standard keyword paired with its numeric code. Apply this whenever you pick, review, or relevel the severity of a log line; it does not govern the message text, the log format, or retention.

Rules

1. The eight levels — keyword, code, and the condition each means. Lower number = more severe.

| code | keyword | the condition it means | | --- | --- | --- | | 0 | Emergency | the system is unusable — nothing works | | 1 | Alert | a human must take action immediately | | 2 | Critical | a critical condition; a component is unusable but the system limps on | | 3 | Error | an operation failed | | 4 | Warning | something is off but the operation still succeeded or self-corrected | | 5 | Notice | a normal but significant event worth recording | | 6 | Informational | routine confirmation the system is working | | 7 | Debug | detail useful only when diagnosing |

1. Assign from the condition, not the mood. The level follows what actually happened, not how

worrying the log line reads. A scary-sounding event that recovered is not an Error; a dull-sounding event that broke the system is not Informational.

1. A failure that self-corrected is Warning (4), never Error. A retry, reconnect, or failover that

ended in success is at most a Warning — the operation ultimately succeeded. Error (3) is for an operation that actually failed and stayed failed.

1. A resource that ran out is Critical (2), not Informational or Warning. A full disk, an exhausted

descriptor pool, or a store that can no longer accept writes has made a component unusable — that is a critical condition, even though the individual message looks routine.

1. Immediate-human-action is Alert (1); whole-system-down is Emergency (0). Reserve Emergency for

"nothing is serving at all." Alert is one step down: still up, but a person must respond this minute. Most day-to-day failures are Error (3) or Critical (2), not Alert or Emergency.

1. Normal-but-significant is Notice (5), not Informational. Startups, planned shutdowns, operator

config changes, deliberate admin actions, and single expected client-side outcomes (one bad password, one rejected oversized upload) are Notice — significant, but not a defect. Reserve Informational (6) for high-volume routine confirmations, and Debug (7) for diagnostic internals.

1. Always emit both the keyword and the numeric code. Write Warning (4), Critical (2) — the pair

is the convention, not one or the other.

Worked examples

The base's mood-based default is on the left; the condition-based level on the right.

BEFORE  ERROR  "connection dropped, reconnected on the next attempt"
AFTER   Warning (4)   # the operation self-corrected — not an Error

BEFORE  INFO   "log volume filled up; further writes are failing"
AFTER   Critical (2)  # a resource is exhausted and a component is now unusable

BEFORE  ERROR  "service finished booting and is accepting requests"
AFTER   Notice (5)    # a normal but significant milestone, not an error

BEFORE  WARN   "kernel oops — the whole node stopped responding"
AFTER   Emergency (0) # the system is unusable

BEFORE  ERROR  "certificate expires in 12 hours; renewals will stop unless rotated today"
AFTER   Alert (1)     # a human must act immediately, though nothing is broken yet

BEFORE  WARN   "single request handler raised an unhandled exception"
AFTER   Error (3)     # one operation failed and stayed failed

BEFORE  INFO   "operator rotated the signing key during the maintenance window"
AFTER   Notice (5)    # a deliberate, significant operator action

BEFORE  INFO   "raw parsed contents of each inbound header"
AFTER   Debug (7)     # diagnostic internals, useful only when troubleshooting

Edge cases & exceptions

• A client's own bad input (wrong password, oversized file, unsupported option) → Notice (5) or

Informational (6). It is expected and not a server defect, so not Error/Warning.

• A degraded-but-serving component (one replica lagging, one node draining) → Warning (4). It is not

yet a critical failure.

• A transient blip that cleared itself → Warning (4) at most; if truly routine and expected, Debug.
• "Critical" vs "Alert" → Critical (2) describes the condition (a subsystem is unusable); Alert (1)

is about urgency of response (a human must act now). A slowly-approaching hard deadline with nothing broken yet is Alert; a subsystem already down is Critical.

• Batch of individually-fine events → keep them Informational/Debug; do not inflate volume to

Warning just because there are many.

Do / Don't

• Do level by the condition. Don't level by how alarming the wording feels.
• Do use Warning (4) for a recovered retry. Don't log a self-corrected failure as Error.
• Do use Critical (2) for an exhausted resource. Don't bury a full disk under Informational.
• Do reserve Emergency (0) for a fully-unusable system and Alert (1) for act-now events. Don't stamp

every failure Critical/Alert/Emergency.

• Do put normal-significant milestones at Notice (5). Don't flatten startups and config changes to Info.
• Do write the keyword with its number. Don't emit only WARN with no code, or only a bare 2.

Common mistakes

• The whole app on a three-rung ERROR/WARN/INFO scale, with Notice, Alert, Emergency, and the 0–7 codes

never appearing.

• A recovered retry or failover logged as Error because it looked bad.
• A full disk or descriptor exhaustion logged as Warning or Info instead of Critical.
• Every failure escalated to Critical/Alert/Emergency regardless of blast radius.
• Startups, planned maintenance, and operator actions logged as Error or Info instead of Notice.
• Emitting only the keyword (or only the number) instead of the keyword+code pair.

Quick checklist

• One of the eight keywords, paired with its 0–7 code.
• Level chosen from the condition, not the tone.
• Recovered failure ≤ Warning (4); real failed operation = Error (3).
• Exhausted resource = Critical (2); whole system down = Emergency (0); act-now = Alert (1).
• Normal-significant = Notice (5); routine = Informational (6); internals = Debug (7).