--- name: syslog-severity-levels source: https://app.decimal.ai/s/syslog-severity-levels@1/SKILL.md source_sha256: 6d6e83d17fe2 --- # 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 | 2. **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. 3. **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. 4. **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. 5. **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. 6. **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. 7. **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).