Syslog Severity Mix Analyzer

Classification mode:

Use Auto for mixed device and application samples.

Error share warning:

Set the share of emerg, alert, crit, and err entries that should trigger review.

Severity threshold:

The active band follows the current error+ share and warning percentage.

Syslog lines:

Paste log lines with optional <PRI>, timestamps, hostnames, programs, and free-text severity words.

Log input needs attention

{{ error }}

Source label:

Use the log slice name that should appear in DOCX and JSON exports.

Severity	Code	Count	Share	Copy
{{ row.severity }}	{{ row.code }}	{{ row.count }}	{{ row.share }}
No severity rows yet Paste syslog lines or load the sample to build the severity ledger.

Emitter	Lines	Error+	Dominant severity	Next action	Copy
{{ row.emitter }}	{{ row.lines }}	{{ row.errorShare }}	{{ row.dominant }}	{{ row.next }}
No emitter rows yet Classified log lines will rank noisy hosts, services, or fallback emitters here.

Paste syslog lines or load the sample to draw the severity distribution.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

During an operations window, the first useful question is often not how many log lines arrived, but how serious those lines claim to be. A collector may receive thousands of entries from routers, firewalls, Linux hosts, appliances, and application services. The severity code describes seriousness, while timestamp, hostname, app tag, and message text point to the part of the environment creating pressure.

The classic severity scale runs from 0 for emergency through 7 for debug. Lower numbers are more severe, so a rise in codes 0 through 3 means the sample has more emergency, alert, critical, or error messages. That is different from total log volume. A busy firewall can produce many informational connection notices without being broken, while repeated error lines from one service can deserve attention even when the overall sample looks calm.

Severity: The seriousness value carried by a syslog priority header or inferred from plain message text.
Facility: The broad source category encoded with severity in a formal priority value, such as kernel, mail, daemon, or local use.
Emitter: The host, application, device, service, or fallback token that appears to be producing the line.

Priority headers are useful because they are compact and standardized. In formal syslog, the priority number inside angle brackets combines facility and severity, so the severity can be recovered with arithmetic instead of guessing from prose. Real-world samples are less tidy. Application logs may say ERROR, WARN, or DEBUG without a priority header, and appliance exports sometimes mix structured and plain text lines in the same copied slice.

Severity mix is most useful as a triage lens. It can help during change review, firewall troubleshooting, alert cleanup, outage reconstruction, and collector tuning. The mix answers a first-pass question: is this slice mostly routine chatter, a warning-heavy burst, or a concentration of severe lines from one emitter? It does not prove root cause, business impact, or service health by itself.

The common mistake is treating percentages as truth without checking the sample. Duplicate bursts, narrow time windows, filtered collectors, vendor-specific wording, missing priority headers, and copied fragments can all distort the mix. A high error share deserves review, while a low error share still needs emitter-level checks when one host or service dominates the severe lines.

How to Use This Tool:

Paste a focused log slice from one time window or collector query. The result is easier to trust when the sample has a clear boundary, such as one incident period, one device group, one service, or one exported search.

Choose Classification mode. Use Auto for mixed syslog and application text, PRI only when every relevant line should have a formal priority header, or Words only when plain text severity terms are the main evidence.
Set Error share warning to the percentage of emergency, alert, critical, and error lines that should trigger review. The default is 20%.
Paste into Syslog lines, load the sample, browse for a .log or .txt file, or drop a text file onto the field. Empty input reports that log lines are needed before the mix can be classified.
Use Source label when DOCX or JSON exports need a collector, site, device group, or service label.
Read Syslog Severity Ledger for the severity distribution, then check Emitter Noise Queue for the hosts or services driving the severe lines. Use Syslog Severity Bar Chart when a count chart helps a handoff note or incident review.

If PRI parsed is low, check word-derived severity against the original product's severity field before using the mix in a final incident report.

Interpreting Results:

The headline error+ value is the share of classified lines with severity 0, 1, 2, or 3. The summary flags error mix high only when that percentage is greater than the selected threshold. At the default threshold, 20.0% is on the boundary and 20.1% is in the review band.

The PRI parsed badge is a confidence cue. A high count means many lines used formal priority values. A low count means the review depended on message words or defaulted unmatched lines to informational severity. Word-based classification is useful for triage, but product-specific wording can still mislead it.

Syslog severity interpretation cues
Output cue	What it suggests	What to check next
`error mix high`	Codes 0 through 3 exceed the selected warning percentage.	Filter the original log search to the top emitters before widening the incident scope.
`Watch` threshold band	The error+ share is near the review threshold, not yet above it.	Check whether the sample is too small, filtered, or dominated by a duplicate burst.
`0 PRI parsed`	No formal priority headers were used for classification.	Compare word-derived severity with the original product's own severity field.
One emitter has high `Error+`	A host, app, service, or fallback token is producing most severe lines.	Inspect timestamps and repeated messages for that emitter in the source log platform.
Overall mix in range but warnings are high	The sample may show degradation or retries without many error-class messages.	Look for change windows, capacity pressure, flapping links, or retry storms.

Technical Details:

A syslog priority value is the decimal number placed between angle brackets at the start of a formal message. It combines two pieces of information: facility and severity. Facility names the broad source category, while severity names seriousness. For severity-mix review, severity drives the main count and facility remains decoding context when a priority header is present.

RFC-style severity is intentionally ordered with the most severe values first. Codes 0 through 3 cover emergency, alert, critical, and error conditions. Codes 4 through 7 cover warning, notice, informational, and debug messages. That order matters because a smaller number means a more severe message, not a smaller problem.

Formula Core

priority = 8 \times facility + severity

severity = priority mod 8

facility = ⌊ \frac{priority}{8} ⌋

error_share = \frac{emerg + alert + crit + err}{total_lines} \times 100

A line that starts with <3> has severity 3, so it counts as err and contributes to error+. A line that starts with <14> has facility 1 and severity 6, so it contributes to informational count instead. If 22 of 100 classified lines are severity 0 through 3, the error share is 22.0%.

Syslog severity codes and error share membership
Code	Label	Typical meaning	Included in `error+`
0	`emerg`	System is unusable.	Yes
1	`alert`	Immediate action is needed.	Yes
2	`crit`	Critical condition.	Yes
3	`err`	Error condition.	Yes
4	`warning`	Warning condition.	No
5	`notice`	Normal but significant condition.	No
6	`info`	Informational message.	No
7	`debug`	Debug-level message.	No

Classification Rules

In Auto mode, a leading priority header is used when one is present, and word-based classification is used for the remaining lines. In PRI only mode, lines without a usable priority value default to informational severity. In Words only mode, priority headers are ignored and message terms drive the classification.

Syslog severity classification behavior
Input evidence	Rule	Result behavior
Leading `<PRI>`	The priority value is limited to the formal 0 to 191 range, then decoded with `priority mod 8`.	Formal severity controls the line when PRI parsing is active.
`emerg` or `panic`	Maps to severity 0.	Counts as error+.
`alert`	Maps to severity 1.	Counts as error+.
`crit`, `critical`, or `fatal`	Maps to severity 2.	Counts as error+.
`err`, `error`, `failed`, `failure`, `denied`, `deny`, `down`, or `timeout`	Maps to severity 3.	Counts as error+.
`warn`, `warning`, `changed`, `retry`, or `degrad`	Maps to severity 4.	Shows warning pressure but does not count as error+.
No priority or recognized word	Defaults to severity 6.	Keeps unknown lines from inflating error share.

Emitter grouping prefers structured hostname and app fields, then BSD-style hostname and tag fields, then key-value hints such as host=, device=, app=, or service=. When those forms are missing, a fallback token is used. Treat the emitter queue as a lead for filtering the original logs, not as a guaranteed inventory of systems.

Privacy and Accuracy Notes:

Log excerpts can contain hostnames, internal IP addresses, usernames, customer identifiers, tokens, request paths, and failure details. The analysis runs in the browser after the page is loaded, and file text is read locally, but copied rows, downloaded CSV or JSON files, DOCX exports, screenshots, and pasted excerpts still need the same handling as the original logs.

Sanitize secrets, account identifiers, and internal addresses before sharing results outside the incident team.
Use a narrow time window when calculating error share, then repeat with a wider window if the first slice looks unusual.
Confirm severe bursts against service health checks, alert history, deployment records, and the original log platform before declaring impact.
Use the settings link for mode and threshold context only; it does not need pasted log text to explain how the review was configured.

Worked Examples:

Firewall sample with priority headers

A firewall search contains 100 lines. Eighteen lines start with <3> and four lines start with <2>. With Error share warning at 20%, the severity ledger shows 22.0% error+ and the summary flags the mix for review. The next useful step is to inspect the emitter queue before paging a broad group.

Application text without PRI

A service log includes checkout failed timeout, retry warning from service, and DEBUG cache key refreshed, but no angle-bracket priority values. Auto classifies those lines from words, while the PRI parsed badge stays low. That is enough for triage, but the original service severity field should be checked before final reporting.

Boundary near the warning threshold

A 50-line slice with exactly 10 error+ lines has a 20.0% error share. With the threshold also set to 20%, the summary is not above the threshold because the review state uses a greater-than comparison. Eleven error+ lines would raise the share to 22.0% and trip the review state.

Noisy emitter hidden in a low overall mix

A 500-line collector slice may show only 4.0% error+ overall, but one service can still have a very high error share inside its own rows. The headline stays in range while Emitter Noise Queue points to the host or service worth filtering in the original log search.

Advanced Tips:

Use PRI only when validating collector parsing, because lines without a formal priority value fall back to informational severity instead of word guesses.
Use Words only when appliance or application exports have reliable severity words but stripped priority headers.
Keep Error share warning stable across before-and-after comparisons, and record the selected percentage with the source label.
Inspect Emitter Noise Queue even when the overall mix is in range; one service can carry most severe lines inside a large informational sample.
Repeat the analysis with a wider time window when a short slice is dominated by duplicate bursts, retries, or a single collector query filter.

FAQ:

Can I paste both syslog and application logs?

Yes. Use Auto for mixed samples. Lines with priority headers are classified from the priority value, and lines without priority headers can fall back to recognized severity words or default to info.

Why did an error-looking line count as info?

The line may not contain a priority header or one of the recognized severity words. Check the original product's severity field, especially when vendor text uses unusual wording or short codes.

What does error+ include?

It includes severity codes 0 through 3: emerg, alert, crit, and err. Warnings are counted in the ledger but do not add to the error+ share.

Why can one emitter matter when the overall mix is normal?

Overall percentages can hide a concentrated fault. A single app, host, or device may produce most severe lines while the rest of the sample is informational noise.

Does a high error share prove there was an outage?

No. It means the pasted sample has more severe lines than the selected threshold allows. Confirm timing, duplicate bursts, affected emitters, service health, and monitoring signals before calling it an outage.

Glossary:

PRI: The priority value in angle brackets at the start of a formal syslog message.
Severity: The seriousness code from 0 to 7, where 0 is emergency and 7 is debug.
Facility: The source category encoded with severity inside the priority value.
Error+: The combined share of emergency, alert, critical, and error lines.
Emitter: The host, app, service, device, or fallback token used to group log lines.
Warning threshold: The configured error+ percentage used to decide whether the sample is flagged for review.

References:

RFC 5424: The Syslog Protocol, RFC Editor, March 2009.
RFC 3164: The BSD Syslog Protocol, RFC Editor, August 2001.
How to filter syslog messages by facility and priority in rsyslog, Simplified Guide.
How to send a test syslog message, Simplified Guide.

Syslog Severity Mix Analyzer

Severity threshold:

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core

Classification Rules

Privacy and Accuracy Notes:

Worked Examples:

Firewall sample with priority headers

Application text without PRI

Boundary near the warning threshold

Noisy emitter hidden in a low overall mix

Advanced Tips:

FAQ:

Glossary:

References: