Syslog levels 0 to 7: How to determine the severity of logs
Last updated on:In this page
What are syslog levels?
Syslog levels are numerical values that determine the severity of an event. These levels are standardized by RFC 5424, using the mandatory priority (PRI) component in the message header. Therefore, the severity levels are by default applicable to all syslog messages.
The severity levels include eight distinct levels that range from 0 to 7. The below table lists the syslog levels from the most to least level of severity.
| Value | Severity | Keyword | Description |
|---|---|---|---|
| 0 | Emergency | emerg | System is unusable |
| 1 | Alert | alert | Action must be taken immediately |
| 2 | Critical | crit | Critical conditions |
| 3 | Error | err | Error conditions |
| 4 | Warning | warning | Warning conditions |
| 5 | Notice | notice | Normal but significant condition |
| 6 | Informational | info | Informational messages |
| 7 | Debug | debug | Debug-level messages |
What each severity level denotes
Each syslog level is associated with specific events pertaining to their severity as follows:
Emergency (0)
This is the highest level, usually indicating a complete failure that affects the entire system or cluster. It denotes a critical event that might render the system futile.
Examples:
- A kernel panic on a critical server that causes the entire OS to halt and restart immediately.
- The corruption of the OS that makes it impossible to initiate a reboot.
- Other catastrophic events that freeze the operating system completely.
Alert (1)
This level of severity is as critical as the emergency level which, with immediate intervention, can be contained. Events under this syslog level require instantaneous action in order to prevent major damage or loss of service.
Examples:
- A situation of complete service outage caused due to the loss of connection with the primary database while the system is running on the last available backup.
- The failure of the database authentication system that interrupts logon, hindering regular operations.
Critical (2)
Events that cause disruptions in the system such as an application crash or failure but do not sabotage the functioning of the entire system fall under the critical level. Though the situation requires immediate action, the system remains partially functional, buying some more time for remediation.
Examples:
- Hardware component failure
- Firewall policy failure
- Errors in the storage device
- Loss of redundant power supply
Error (3)
Events that fail to execute according to the network or security policies are denoted by severity level three. These events do not impact system functions or cause operational disturbances but act as initial indications that flag suspicious activity. These events serve as IoCs of an ongoing or impending cyberattack.
Examples:
- Authentication failures due to wrong passwords
- Multiple failed logons
- DNS lookup failures
Warning (4)
Events of this level are mostly non-critical and act as an intimation for an impending issue or problem.
Examples:
Instances of high disk usage, high CPU load, and certificate expiration.
Notice (5)
This severity level is used to indicate events that are important to be notified and recorded but not potentially errors or events that cause detrimental issues to the system.
Examples:
Events such as service started or stopped or critical configuration changes.
Informational (6)
Events of this level are mostly routine processes or tasks that possess only informational context about system operations with no significant impact on the system.
Examples:
Successful logon or log off events, process completions, and backup status updates.
Debug (7)
This level includes granular telemetry data that is useful for system diagnostics and troubleshooting.
How to configure syslog levels
Syslog level configuration occurs at two stages as follows:
Configuration of log source
At the log source (router, server, firewall), the minimum severity level of logs to be sent out are configured using a command specifying the logging trap. A logging trap is the configuration setting on the network device that determines the minimum severity level of system messages that will be sent to an external syslog server.
For instance, if the logging trap is set to Warning (level 4), it will cause the device to forward all logs with severity level 4 to the syslog server.
Configuration of log receiver
At the log receiver i.e., a syslog server or the log management tool, logging rules are configured to receive, filter, and store the incoming messages from the log sources. The server rules typically use the severity level as a filter to collect only messages of the configured level. For instance, a rule might direct all messages of Error (level 3) to a specific facility to trigger an alert.
To filter noise, prioritize alerts, and boost your operational efficiency using standardized syslog practices, take a look at our syslog basics guide.
Significance of severity levels in syslog monitoring
The severity levels serve as filters that help reduce noise, streamline syslog monitoring, and prioritize critical events. The core functionalities of these levels include:
- Message filtering: The severity levels help administrators configure the log collector to accept messages at a specific level and set up a filter threshold to prevent the syslog monitoring system from being overwhelmed with noise.
- Event prioritization: The levels facilitate monitoring, and alerting tools map the severity level directly to a response procedure. This ensures that critical issues are addressed before minor ones, preventing alert fatigue in security analysts.
- Alerting: Severity levels are directly tied to automated alerting systems in modern monitoring tools. These tools are configured with thresholds that execute predefined actions based on the incoming level, enabling proactive alerting.
- Automation enablement: Log analysis tools such as SIEM, EDR, or XDR use the severity levels as a trigger for automated workflows that help automate incident management and response.
- Compliance tracking: Compliance requirements often mandate specific events like failed login attempts or configuration changes to be logged. As such events are assigned clear severity levels, the security logs can be easily filtered and audited, allowing seamless compliance tracking.
How severity levels are leveraged in EventLog Analyzer
ManageEngine EventLog Analyzer leverages the syslog severity levels for alerting, reporting, and filtering logs. When EventLog Analyzer receives a syslog message, the log is parsed based on the severity. This allows administrators to perform the following activities:
- Configure real-time alerts for critical events, ensuring immediate notification via email or SMS when an Emergency or Critical log is received.
- Generate severity-based reports, allowing quick filtering to see all Warning logs from firewalls or all Error logs from a specific server.
- Perform forensic analysis by searching logs, quickly narrowing down millions of records to only those with a high severity to investigate a security incident.
This enables efficient prioritization of security and operational issues.
Frequently asked questions
There are eight severity levels in syslogs, ranging from 0 to 7. These include: Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Informational (6), and Debug (7).
Syslog level 6 (Informational) is used for informational messages. These logs record normal system operations that do not require urgent action, such as successful user logins or routine status updates.
Syslog level 0 (Emergency) is the most severe. Events at this level indicate complete system failure or outages requiring immediate attention to prevent widespread disruption.
Syslog level 7 (Debug) is the lowest severity level. It is primarily used for diagnostic messages and detailed troubleshooting information that typically does not require user attention.
Syslog levels describe the urgency or severity of an event, while syslog facilities identify the source or category of the process that generated the message. Severity indicates importance; facility indicates origin.
It is not possible to create custom syslog severity levels, as levels 0–7 are standardized by the syslog protocol. However, applications can internally map custom categories to existing severity levels to match their own event-classification needs.
Security events often use Warning or Error levels for suspicious activity or policy violations. More severe incidents requiring immediate investigation may use Alert or Critical, whereas routine observations may be logged under Informational or Notice.
