Hosting Operations
Read-only, can be slowSummarize Journal Severity During an Incident
An alert fired and you need to know whether the recent journal is mostly warnings, errors, or critical failures.
Command
journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nrBefore you run this
System impact: Read-only. Can create load on large logs, directories, filesystems, or process tables.
When not to use it: Do not use severity counts as root cause; follow up by grouping by unit and reading the timeline.
Expected output
Counts followed by journal priority names.
System impact
Read-only, can be slow. Nothing changes. The command counts journal lines by severity.
Scope this to the smallest useful path or service on busy systems.
Recovery / rollback: no state is changed.
When to use it
Use at the start of incident triage when you need a fast severity profile.
When not to use it
Do not use severity counts as root cause; follow up by grouping by unit and reading the timeline.
Watch this command run
Command transcript
This sanitized transcript shows the commands and output shape without exposing host details.
$ journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso
2026-06-25T14:02:06+00:00 vps api[1842]: warning upstream_slow upstream=db latency_ms=2200
2026-06-25T14:03:08+00:00 vps api[1842]: err request_id=req-103 ERROR database timeout after 30000ms
2026-06-25T14:03:12+00:00 vps api[1842]: err request_id=req-103 ERROR retry failed upstream=db
2026-06-25T14:05:10+00:00 vps worker[2201]: crit FATAL job runner exited code=137
2026-06-25T14:05:12+00:00 vps systemd[1]: warning worker.service restarted
2026-06-25T14:06:33+00:00 vps api[1842]: err request_id=req-107 ERROR payment provider returned 500$ journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nr
3 err
2 warning
1 critView commands shown
These are the commands shown in the sanitized transcript.
Commands shown
journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-isojournalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nr
next steps
Related commands
Group Journal Errors by Unit
A noisy incident usually has a noisy source.
journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{split($3,a,"["); unit=a[1]; count[unit]++} END {for (u in count) print count[u], u}' | sort -nr
Print a Critical Journal Timeline
Timeline beats guesswork when several failures happen close together.
journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'
Count App Errors by Minute
A minute-by-minute count shows whether an incident is a spike or a drip.
awk 'tolower($0) ~ /(error|fatal|timeout|exception)/ {minute=substr($1,1,16); count[minute]++} END {for (m in count) print count[m], m}' fixtures/incidents/app.log | sort -nr
Summarize HTTP Status Codes
Before chasing individual lines, get the shape of the whole log.
awk '{count[$9]++} END {for (code in count) print count[code], code}' ./fixtures/nginx/access.log | sort -nr
Group Server Errors by URL Path
A 500 spike is easier to triage when the broken path is obvious.
awk '$9 ~ /^5/ {count[$7]++} END {for (path in count) print count[path], path}' ./fixtures/nginx/access.log | sort -nr | head
Study mapping
Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.
Useful for
- LPIC-1 style command-line practice
- LFCS style performance tasks
- Linux+ style troubleshooting review
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.