Home › Error Grouper
Group log errors into distinct problems
Direct answer: drop a log file below. The grouper assembles multi-line entries (stack traces stay attached to their error), masks timestamps, IDs, IPs and numbers, then matches entries on the masked message plus the top application frame — and ranks the result by severity × frequency. Local processing only; redaction is on by default everywhere.
Group this 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.
How it works
- Drop the log file (or paste an excerpt) into the panel.
- Press Group errors. The file is processed in your browser — watch progress, cancel any time.
- Read the Triage Board: problems ranked by severity × frequency, singletons listed apart.
- Inspect a group for its pattern, samples and occurrence list; export the incident report if it needs to travel.
The method, in plain language
Assemble. A log entry is rarely one line. Java exceptions arrive with frames and
Caused by: chains; Python prints a header, a traceback, and sometimes a second traceback chained
to the first; Go panics print a signal line and a goroutine stack. Assembly keeps all of that attached to its
error, so a trace never shatters into per-frame noise. The full walk-through is in
how to group repeated errors in a log.
Mask. Two occurrences of one problem differ in exactly the values you don't care about:
when it happened, which order, which user, which IP. Masking replaces those with placeholders —
<ts>, <n>, <ip>, <uuid>,
<str> — in a fixed order, so the comparison is stable.
Fingerprint & rank. For exception entries the fingerprint is the exception class + top application frame + masked exception line. For plain messages it is the masked message (plus the logger channel when the format provides one). Groups are ranked by severity weight × log-scaled frequency, so a FATAL seen 3 times outranks an INFO seen 300 times — and a WARN seen 30,000 times still surfaces.
Honest limits
Grouping is normalisation, not diagnosis: it cannot tell you why the payment gateway timed out, only that it did, 212 times, starting at 09:16. A group whose samples disagree with its pattern is a signal to look closer, not a bug to report blindly. And if your file is an access log rather than an application log, use Access-Log Triage — request records group differently. New to traces? How to read a stack trace comes first.
Frequently asked questions
Which log formats does the grouper handle?
Plain application logs (Java/Spring, Node, Go and most timestamped text formats), Python tracebacks including chained exceptions, Docker JSON-file driver records and Docker Compose output, Kubernetes pod logs including klog lines and Go panic blocks, JSONL/structured logs with msg/level fields, and syslog. Access logs have their own tool — they are request records, not error entries.
Why does the same exception sometimes appear twice in my codebase but group once here?
Grouping keys on the exception class, the masked exception message, and the top application frame — the throw site. The same exception thrown from the same place with different values (different order IDs, users, timestamps) is one problem. The same exception class thrown from a different frame is a different problem, because the fix lives in different code.
What does "seen once" mean — should I ignore singletons?
A singleton is a distinct entry that occurred exactly once in the file. Many are noise (a single health check), but a single FATAL at 03:12 can be the whole incident. Singletons are listed separately precisely so they are neither inflated into "problems" nor silently dropped.
Can I share the board with my team?
Export the incident report (Markdown) from the board: it contains the summary, the ranked problems with redacted samples, and the singleton count. Exports are always redacted, even if you turned the raw view on for your own screen. The redacted full log can also be downloaded when the team needs the whole file.
What does the "distinguish short quoted strings" option do?
By default, quoted literals in messages are masked, so KeyError: 'user_881' and KeyError: 'user_992' group together. With the option on, short quoted values (up to 24 characters) stay visible in the fingerprint, splitting groups whose short strings differ — useful when the string is a state or code, harmful when it is an ID. It applies to the next run.