PostgreSQL Log Parser

PostgreSQL logs are verbose but parseable. PostgreSQL Log Parser reads each line’s timestamp, PID, session user and database, severity, and message, then organizes the file into severity counts, normalized error groups, the slowest statements, and activity per database and user.

Routine LOG and NOTICE traffic is separated from real failures, while ERROR and FATAL entries are grouped so the same underlying problem is counted once — not repeated hundreds of times.

• Full line parsing — time, PID, user, database, level, message.
• Severity tally — errors vs warnings vs routine logs.
• Normalized error grouping — noise masked.
• Slow statement ranking — duration extraction.
• Per-database and per-user breakdown.
• Local only — nothing uploaded.

1. Paste your postgres log — the standard timestamp timezone [pid] user@database LEVEL: message line shape. Lines missing the user/database segment (background workers, startup messages) are still parsed, just without those two fields.
2. Set the group depth if you want to see further down the ranked lists than the default top 10 — handy on a busy log with a long tail of distinct error patterns.
3. Click Parse log. Every line is classified by severity, and ERROR/FATAL/PANIC/WARNING messages are additionally normalized and grouped so the same underlying failure is counted once.
4. Drill into error patterns first, then check slow statements if log_min_duration_statement or log_duration was enabled for that log, then check the per-database/per-user breakdown to see where the activity is concentrated.
5. Copy the report for a ticket or an incident writeup.

Example 1 — Constraint storm. A schema change breaks inserts; hundreds of ERROR: null value in column "x" violates not-null constraint lines collapse into one group with a count, because the normalizer replaces every quoted identifier with a placeholder before grouping — so the pattern reads the same whether the failing column is "email" or "customer_id".

Example 2 — Slow reporting query. duration: 15200.123 ms lines rank the offending statements with the database and user that ran them, so a report-generation job that quietly got slower over time surfaces at the top of the slow-statement list instead of hiding among thousands of routine LOG lines.

Example 3 — Auth failures. Repeated password authentication failed for user "x" entries group by pattern (with the username masked out) while the per-database breakdown shows which cluster is under attack — a sudden count of grouped auth failures against one database is a strong signal of credential stuffing or a misconfigured client retrying with a stale password.

Example 4 — Noise filtering. A busy production log can be 95% routine LOG: statement: lines; because only ERROR/FATAL/PANIC/WARNING lines are grouped and counted toward the error patterns section, that routine traffic never crowds out the handful of lines that actually need attention.

• Signal separation — real failures vs routine logs.
• Error pattern groups — one count per root cause.
• Performance view — slowest statements ranked.
• Context fields — user, database, PID preserved.
• Private — all processing client-side.