{{ summaryHeading }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ thresholdLabel }} {{ classifiedLabel }} {{ resolutionLabel }}
Raw log text is never added to the URL or sent to a service.
{{ sourceError }}
{{ fileStatus || 'Drop one LOG or TXT file onto the textarea.' }}
Auto resolves each line independently and reports how many used PRI, word, or informational fallback handling.
{{ warning_error_pct }}%
Review activates when the classified error-plus share is at or above this percentage.
%
Kept local because operational labels can reveal internal infrastructure.
Source labelSeverityCodeCountShareHandlingCopy
{{ sourceLabel }}{{ row.severity }}{{ row.code }}{{ row.count }}{{ row.share_label }}{{ row.meaning }}
Source labelEmitterLinesError-plus shareDominant severityReviewNext actionCopy
{{ sourceLabel }}{{ row.emitter }}{{ row.line_count }}{{ row.error_share_label }}{{ row.dominant_severity }}{{ row.review }}{{ row.next_action }}
{{ chartError }}
Application Log Pattern Analyzer Group application logs into stable fingerprints, compare severity and time clusters, and triage recurring patterns without uploading the source.
Audit Log Anomalies Analyzer Rank suspicious audit events from common log and CloudTrail exports using transparent signals for failures, source shifts, and privilege changes.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.
Git Diff Risk Analyzer Rank Git diff files by churn and repository risk signals, with transparent scores that guide owner review without claiming merge safety.

An incident window can contain thousands of routine events and only a few messages that deserve immediate attention. A severity mix turns that stream into counts and shares, making it easier to tell a broad rise in serious events from ordinary background volume. The same comparison helps after deployments, during alert tuning, and when one host or application appears noisier than its peers.

Syslog severity uses an inverse scale. Emergency is code 0 and Debug is code 7, so a lower number means a more urgent condition. Facility answers a different question by identifying the source category. In a valid syslog priority value, facility and severity are packed together; they should not be treated as two names for the same signal.

EvidenceWhat it can showMain caution
Severity countHow many classified events fall at one levelLonger samples naturally produce larger counts
Severity shareHow the classified sample is distributedA small denominator can exaggerate one event
Emitter shareWhich inferred source contributes the serious eventsSource extraction depends on recognizable log layouts
Error-plus shareThe proportion at Emergency through ErrorA review gate is a local heuristic, not an outage definition

Structured syslog carries an explicit priority header, but many application logs only contain words such as “error” or “warning.” Those words are useful for triage when the application uses them consistently. They are not standardized across every product, and an unmarked line may have to be treated as informational. The producer's logging policy and the original message remain the authority.

Counts and percentages answer different questions. A surge of informational messages can reduce the error-plus percentage even when the number of errors rises, while one error in a two-line sample produces 50%. Compare similar time windows, keep the classification method fixed, and check absolute counts before changing routing or escalation rules.

How to Use This Tool:

Use one representative sample and choose the rule that matches how its severity is recorded.

  1. Paste the events into Syslog lines or load one LOG or TXT file. If the source is rejected, reduce it to 500,000 characters or fewer and keep at least one nonblank line.
  2. Choose Auto detect for mixed input. Use PRI header only when unmarked lines must remain unclassified, or Severity words only when priority headers should be ignored.
  3. Set Error-plus warning from 0% to 100%. The review state begins when the calculated share equals the selected percentage, not only when it exceeds it.
  4. Check the classified count and classification resolution before acting on the severity distribution. Then inspect emitters marked Review against the original messages and the relevant service state.

Interpreting Results:

The error-plus percentage is the primary review signal, but its denominator contains only classified lines. A large unclassified count weakens confidence in the mix. In word-based classification, the informational fallback count also matters because it shows how many lines lacked a recognized severity word.

  • Treat an emitter marked Review as a place to inspect, not proof that the emitter caused an incident.
  • Compare Count with Share so a change in sample volume does not masquerade as a change in severity.
  • Repeat the analysis with the same mode, threshold, source boundary, and time window before comparing two samples.

Technical Details:

A syslog priority value is accepted only when it appears at the start of a line in angle brackets and lies from 0 through 191. The severity is the remainder after division by 8; the facility is the integer quotient. Auto detection uses that valid priority first, then applies the word rules when no valid priority is present.

Rule Core:

CodeSeverityMeaningError-plus
0EmergencySystem unusableIncluded
1AlertImmediate actionIncluded
2CriticalCritical conditionIncluded
3ErrorError conditionIncluded
4WarningWarning conditionExcluded
5NoticeNormal but significantExcluded
6InformationalInformational messageExcluded
7DebugDebug-level messageExcluded

Word classification checks the most urgent patterns first. Emergency or panic maps to code 0; alert to 1; critical or fatal to 2; error, failure, deny, down, or timeout to 3; warning, retry, degraded, or changed to 4; notice to 5; and debug or trace to 7. Any remaining line becomes Informational at code 6. In PRI header only mode, a line without a valid priority stays unclassified instead.

Formula Core:

Error-plus combines severity codes 0 through 3 and divides their count by the number of classified lines.

Perror+ = n0+n1+n2+n3 Nclassified ×100

The percentage is retained to six decimal places for the result and shown to one decimal place in tables. Review is true when the percentage is greater than or equal to the selected warning gate. The same inclusive comparison is applied per emitter when that emitter has at least one classified line.

Emitter extraction:

Common RFC 5424, traditional timestamped syslog, ISO-timestamped, key-value, and leading level-name patterns supply an emitter label. Lines that match none of those shapes are grouped as unknown. Emitter grouping is therefore a deterministic convenience for triage, not an authenticated source identity.

Privacy and Accuracy Notes:

Log text and the optional source label are processed in the browser and are not added to the URL or sent to a service. Local processing does not remove secrets already present in an export or screenshot.

  • Word matching is a repository-authored heuristic, not part of the RFC severity standard.
  • Blank lines are ignored, and the source label changes export context without changing the analysis.
  • Redact credentials, tokens, personal data, and internal addresses before sharing derived artifacts.

References: