Log Triage
Surface high-signal incidents- !Memory exhaustion / OOM event — 1 matching line(s).
- △Authentication or access failure — 1 matching line(s).
- △Service failure or timeout — 2 matching line(s).
Introduction
Log Triage scans pasted journal or syslog lines and counts matches against four high-signal categories: memory exhaustion (OOM), crashes and data-integrity signals, authentication failures, and generic service failures or timeouts.
Logs are noisy by nature. The tool's job is to reduce the noise to the few lines that usually deserve an incident response, so you can jump straight to the relevant context.
Objective
- Count OOM-kill and out-of-memory events, which indicate memory pressure.
- Count crash, segfault, panic and corruption signals, which indicate stability or integrity problems.
- Count authentication failures, which may indicate brute force or misconfiguration.
- Count service failures and timeouts, the everyday cause of degraded systems.
Inputs
- A paste of journal output (journalctl -n 500 --no-pager), syslog lines or application logs.
- One log line per paste line; any timestamp format is accepted since matching is keyword-based.
How it works
Each pasted line is tested against four regular-expression groups in order: OOM keywords (out of memory, oom, killed process), crash keywords (segfault, panic, corrupt), authentication keywords (failed password, authentication failure, denied), and failure keywords (failed, error, timeout).
Every match increments the counter for its group. A single line can count in more than one group, mirroring how a human reading the log would flag it.
Groups with zero matches are omitted from the result, so a quiet log produces a single clean result.
Testable example
Try it — the analysis runs locally in your browser.
Example
Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (java) Aug 22 14:06:14 node1 sshd[9201]: Failed password for invalid user admin Aug 22 14:07:02 node1 systemd[1]: backup.service: Failed with result 'exit-code'
Expected output
High: Memory exhaustion / OOM event — 1 matching line. Warning: Authentication or access failure — 1 matching line. Warning: Service failure or timeout — 1 matching line.
Reading the output
- OOM events point to memory pressure: check cgroup limits, swap and the process that was killed.
- Authentication failures deserve a look at who is trying and how often; repeated invalid-user attempts often indicate scanning or brute force.
- Service failures (Failed with result 'exit-code') are best investigated with journalctl -u <unit> -e to see the exit code and the lines around it.
Risks
- Keyword matching produces false positives and misses context — a line saying "no errors found" contains the word error and will be counted.
- Treat counts as triage, not as proof of an incident.
- The tool never reads your logs from disk; it only sees what you paste, which is the privacy design of the whole site.
Limitations
- It does not parse timestamps, correlate events across hosts or detect sequences.
- Regex groups are deliberately simple; custom patterns are not supported.
- It is a triage aid, not a SIEM.
Official references
FAQ
Why does a clean-looking line get flagged as an error?
Because matching is keyword-based. A line such as "no error found" contains the token error. If that bothers you, refine the paste to the lines that matter.
What should I do after an OOM event?
Identify the killed process, check its memory limit and the host's memory pressure, then decide whether to raise limits, reduce concurrency or add memory.
Can this replace my monitoring?
No. It is a manual triage helper for pastes. Continuous monitoring, alerting and correlation need a proper logging stack.