Home / Blog / SIEM and Tools
Log Levels Explained: What INFO, WARN and ERROR Mean in Logs
A beginner guide to log severity levels in syslog, Python, Log4j and Windows, why they differ between products, and why quiet INFO events can still matter.
Every log line carries a label such as INFO, WARN or ERROR that shows how important the software thinks the message is. This guide explains what those labels mean, why they differ between products, and why the quiet ones can still matter in an investigation.
Scenario: Your dashboard is filtered to "Error and above" and shows 12 results, all about a print spooler on SRV-PRINT-02. Meanwhile, at 02:13, a new service was installed on WS-114 and logged as Information. Which one deserves your attention first, and why could the quiet one be the more important?
What is a log level?
A log level (also called a severity level) is a label added to a log message by the software that wrote it. It answers one simple question: how serious does the developer think this event is?
Levels exist so that people can filter. A busy server can produce millions of lines a day, and most of them are routine. Levels let an engineer say "show me only the problems" or "show me everything while I fix this bug".
Most software also uses the level as a threshold. If a program is set to log at WARNING, it writes WARNING and anything more severe, and it quietly drops the rest. Python's standard logging module works this way, and its default threshold is WARNING, so debug and info messages do not appear unless someone turns them on.
The syslog scale: eight levels, 0 to 7
Syslog is the standard way many Linux systems, network devices and firewalls send log messages. Its format is defined in RFC 5424. An RFC (Request for Comments) is a numbered document that describes an internet standard.
Every syslog message starts with a PRI value (short for priority). The PRI combines two things: the facility, which says which part of the system sent the message (for example the authentication system), and the severity, which says how serious it is. Facility tells you the origin. Severity tells you the urgency.
| Number | Name | Meaning |
|---|---|---|
| 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 |
Watch out: in syslog, the lower the number, the more severe the message. Level 0 is the worst and level 7 is the quietest. Many other tools count the opposite way.
Other products use different scales
Syslog is only one scale. Applications and operating systems each bring their own list, and the names and the order are not identical. You cannot assume that "ERROR" in one product means exactly the same as "Error" in another.
| Source | Levels, most severe first | Worth knowing |
|---|---|---|
| Syslog (RFC 5424) | Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug | Numbered 0 to 7, lower is worse |
| Apache Log4j 2 (Java logging) | FATAL, ERROR, WARN, INFO, DEBUG, TRACE | FATAL is the most severe. OFF and ALL are settings, not message levels |
| Python logging | CRITICAL, ERROR, WARNING, INFO, DEBUG | Numbered 50, 40, 30, 20, 10, so higher is worse. FATAL is an alias for CRITICAL |
| Windows Event Log | Critical, Error, Warning, Information, Verbose | The Security log records Audit Success and Audit Failure instead |
Notice the trap: Python counts upwards as things get worse, while syslog counts downwards. Always check which way a product runs before you build a filter such as "level greater than 3".
Tip: if your notes list TRACE, DEBUG, INFO, WARN, ERROR and FATAL, that is the Log4j style list, and FATAL is the top of it. It is a common convention, not a universal rule.
How to think about levels on shift
Instead of memorising every name, group levels into three bands. This makes any product easier to read.
Detail
Very chatty messages meant for developers fixing a fault. Usually switched off in production.
DEBUG, TRACE, VerboseNormal running
Things that happened as expected: a service started, a user signed in, a job finished.
INFO, Notice, InformationTrouble
Something failed or might fail soon. Start here when a system is unhealthy.
WARN, ERROR, CRITICAL, FATALBand 3 is where system administrators look when something is broken. Band 2 is where a lot of security evidence hides, because attackers use normal features. A new service being installed, a successful sign in from a strange place and a scheduled task being created are all "normal running" events as far as the software is concerned.
In the scenario above, the print spooler errors are noisy and probably harmless. The new service on WS-114 is logged at Information level, yet it could be a persistence mechanism (a way for an attacker to survive a reboot). Severity is the software's opinion. Risk is your judgement.
What a level cannot tell you
Filtering by level: four short searches
You do not need complex queries to use levels. Here are four small examples. The host names and values are placeholders, so adjust them to your environment.
Linux: journalctl
journalctl -p err --since "1 hour ago"This reads the systemd journal. The -p err option means priority "err" and anything more severe, so you also get crit, alert and emerg. --since limits the output to the last hour.
Windows: PowerShell
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 1,2; StartTime = (Get-Date).AddHours(-1) } |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName |
Format-Table -AutoSizeThe first line reads the System log. In this filter, Level 1 means Critical and Level 2 means Error, and StartTime keeps the last hour only. The second line picks the columns to show, and the third prints them as a table.
Microsoft Sentinel: KQL
KQL (Kusto Query Language) is the query language used in Microsoft Sentinel, a cloud SIEM (Security Information and Event Management) tool.
Syslog
| where TimeGenerated > ago(1h)
| where SeverityLevel in ("emerg", "alert", "crit", "err")
| summarize Count = count() by Computer, ProcessName
| sort by Count descLine 1 chooses the Syslog table. Line 2 keeps the last hour. Line 3 keeps only the four most severe syslog levels. Line 4 counts messages per machine and process, and line 5 shows the noisiest first.
Splunk: SPL
SPL (Search Processing Language) is the query language used in Splunk. The index, sourcetype and field names depend on how your organisation set Splunk up.
index=app_logs sourcetype=webapp level=ERROR earliest=-24h
| stats count by host
| sort -countThe first line searches one index for ERROR events from the last 24 hours. The second counts them for each host. The third sorts the biggest count to the top.
Common mistakes to avoid
Watch out: filtering a SIEM to "errors only" is convenient, but it hides most successful attacker actions. Use levels to organise your reading, not to decide what is safe.
- Check which way the scale runs before filtering on a number.
- Confirm what threshold each log source is set to, so you know what is never sent.
- Remember that debug logging can record sensitive details, so treat debug logs carefully if you ever find them in a SIEM.
- Do not trust the label alone. Read the message, the account, the host and the time.
- Make sure clocks agree across systems, or your timeline of events will not line up.
What to study next
CompTIA's CySA+ (CS0-003) exam objectives place log ingestion, time synchronisation and logging levels in the first domain, Security Operations. Check the current objectives document on CompTIA's website for the exact wording, since exam versions change.
- Time synchronisation with NTP (Network Time Protocol) and why wrong clocks break investigations.
- How logs travel from a device to a SIEM: agents, syslog forwarding and batch uploads.
- Windows Event IDs, such as 7045 for a new service and 4625 for a failed logon.
- Practise: open Event Viewer on a lab machine, filter the System log by Error, then by Information, and compare what each shows.
Key takeaways
- A log level is the software's own label for how serious a message is.
- Scales differ: syslog runs 0 to 7 with 0 the worst, Python runs 10 to 50 with 50 the worst, and Log4j puts FATAL at the top.
- Group levels into detail, normal running and trouble to read any product quickly.
- Attacker activity often appears at INFO level, so never filter to errors only and assume you are safe.
- Always check the source's threshold, because levels below it are never logged.
Log levels are one of the first things worth learning, because they shape every search you will write. Open a log in your own lab today, find the level field, and see how many different values it uses.
Written by Ben, Cybersecurity Student