Journalctl Log Formatter

journalctl output is dense: a timestamp, host, unit, a bracketed PID, then the payload — and multi-line messages split across rows. Journalctl Log Formatter aligns every entry into time | host | unit | msg columns, folds continuation lines and -- separators back into their parent message, and keeps PID tokens visible.

The per-unit, per-host, and per-hour summaries turn a wall of systemd text into the short answer: “which unit talked, when, and how much.”

Two output shapes are recognized: the default short format (Jun 11 14:00:00 host unit[pid]: message) and the ISO timestamp variant produced by journalctl -o short-iso or filtered with --since/--until (2025-06-11 14:00:00 host unit[pid]: message). A line that matches neither pattern is treated as a continuation of the previous entry — the exact behavior you want for stack traces, multi-line JSON payloads, or the blank -- reboot separators journalctl inserts, all of which get folded back into the owning entry with an arrow (→) joining the pieces instead of being scattered as orphaned rows. Error flagging looks for common failure words (ERROR, error, Fault, fault, failed, Fail, crash, panic) anywhere in the folded message, including its continuation lines, so a message whose failure keyword only shows up on line two of a traceback still gets tagged.

• Short & ISO formats — both common journalctl output layouts, auto-detected per line.
• Multi-line folding — continuation lines and -- reboot separators are joined back into their parent message.
• Unit + PID column — service identity preserved as unit[pid].
• Error flagging — failure-looking lines (ERROR, Fault, failed, panic, crash, ...) tagged with a leading ! marker.
• Per-hour / per-unit / per-host summaries — quickly spot the busiest service, host, or time window.
• Local only — nothing uploaded, formatting runs entirely in the tab.

1. Paste journalctl output — short or ISO format, straight from journalctl -u myservice or a saved log file.
2. Format. Rows align into time/host/unit/message columns; continuation lines fold into their parent entry.
3. Scan flagged errors and the unit leaderboard to see which service is failing and how often.
4. Copy the report for the log review, incident channel, or postmortem doc.

Example 1 — Boot replay. Pasting a boot-time log shows which units started when and whether any crashed mid-boot, since a failed unit’s error message stays attached to its startup entry instead of appearing as a disconnected line.

Example 2 — Chatty service. The by-unit histogram names the daemon that floods the journal — useful before tuning log verbosity or a systemd rate-limit setting.

Example 3 — Cross-host review. With logs from several hosts pasted together, the host summary compares activity levels at a glance without manually grouping lines by hostname.

Example 4 — Deadlock triage. A Postgres ERROR: deadlock detected entry followed by an indented retry line folds into one flagged, readable record instead of two separate rows that are easy to miss in a long paste.

• Widely compatible — the two most common journal output layouts.
• Message fidelity — multi-line payloads stay intact and readable as one entry.
• Identity rich — unit and PID stay visible for every row.
• Failure aware — suspicious lines are flagged automatically, even across continuation lines.
• Private — all processing happens client-side.