Log triage: group the errors, rank the problems, skip the scrolling
Direct answer: drop a log file below and LogTriage groups its repeated errors into distinct problems — each with a count, severity, first/last seen and samples — ranked by severity × frequency. It streams files up to ~500 MB locally in your browser. Nothing is uploaded, and secrets are redacted by default in every view and export.
Triage a log now
⚠ Raw values are visible on this screen only. Saved board data and every export stay redacted — exports never contain raw values.
Time range in file: —
This board was restored from this browser's storage — stored samples are the redacted copies by design. The raw-view toggle has no effect on restored boards.
| Severity | Problem (first sample line) | Count | First seen | Last seen |
|---|
No repeated problems — every entry in this file was seen exactly once. Check the singletons below.
Singletons — entries seen exactly once
Grouping is deterministic normalisation: timestamps, IDs, IPs and numbers are masked, then entries are matched on the masked message plus the top application frame. It groups — it does not diagnose. Check a group's samples before you act on it.
Triage tools
Three tools, one job: find out what the log is actually saying.
Error Grouper
The flagship. Assembles multi-line entries, masks the values that change between occurrences, and groups by message + top frame. Exports a Markdown incident report.
Access-Log Triage
For Nginx/Apache access logs: status distribution, busiest hours, and error paths grouped with numeric IDs masked — so 400 hits on /products/<n> read as one problem, not 400.
SEO Bot-Log Checker
Which crawlers actually visited, how often, and what errors they hit — Googlebot, GPTBot, ClaudeBot and the rest, identified by user-agent with the spoofing caution printed on the page.
Redaction & privacy
Log Redactor
Scrub keys, tokens, passwords, emails, IPs and card numbers out of a log excerpt before it goes into a ticket, a chat, or a public forum. Redaction is on by default inside every tool above, too — this is the standalone fast path, and the privacy page states exactly what is saved, where, and how to clear it.
Why grouping, not scrolling
Production logs fail you in a specific way: the one error that matters repeats 4,000 times, interleaved with everything else. Reading top-to-bottom, you meet the same problem hundreds of times and still don't know how many distinct problems the file contains. Grouping inverts the file: distinct problems first, each with its frequency — which is the order you actually fix things in.
The method is deliberately boring and deterministic — how to group repeated errors in a log explains it step by step, and the same steps work by hand on a small file. When the file is too big for that, start with what to do when a log file is too big to open.
Guides
The method, the formats, and the craft around the tools — container logs have their own shape, stack traces have a reading order, and a log excerpt should never travel unredacted:
- How to group repeated errors in a log
- Docker logs triage
- Kubernetes logs triage
- Log file too big to open?
- How to read a stack trace
- Find errors in an Nginx access log
- Is Googlebot crawling your site?
- AI crawlers in your server logs
- Redact logs before sharing
- Write an incident report from logs
Frequently asked questions
What does LogTriage actually do?
It groups a log file into distinct problems. Instead of scrolling ten thousand lines, you get a board: each repeated error as one row with its count, severity, first and last seen, and samples — ranked so the severe, frequent problems come first. It is a triage tool: it tells you what is in the file and how often, so you can decide what to fix first.
Is my log uploaded anywhere?
No. Files are read in slices and processed in the background, inside your browser. There is no upload endpoint and the tools make no network requests with your data. Board aggregates can be saved in your browser so the board survives a reload — samples are saved redacted, and you can clear them from the board at any time.
How big a log can it handle?
The design target is ~500 MB. Because processing is streamed and only aggregates are kept (never the whole file in memory), the practical ceiling is your device, not an arbitrary product limit. If a run is going slowly you can cancel it and still get the board for the part already read.
How does grouping decide two lines are "the same problem"?
Deterministically: multi-line entries are assembled first (a stack trace stays attached to its error), then timestamps, UUIDs, IPs, numbers, hex and ID-shaped tokens are masked, and entries are matched on the masked message plus the top application frame. The same exception from the same throw site groups together even when its values differ; the same message text from a different throw site does not merge. No machine learning, no guessing — the same file always produces the same board.
Are secrets in my log safe to look at here?
Redaction is on by default: common secret shapes (cloud keys, JWTs, bearer tokens, passwords, session IDs, emails, IPs, payment cards that pass a checksum) are replaced in samples on screen, in anything stored, and in every export — exports are redacted even if you switch the on-screen raw view on. Redaction is pattern-based, so read a sample once before sharing it anywhere.