Impact, not volume
For each error: how many distinct visitors hit it over seven days, and how many still triggered a business event afterwards — an order, a sign-up. The others left. They are what ranks the list.
Twelve visitors hit this error. None of them paid.
A classic error tool shows you ten thousand occurrences of a harmless exception, and the one that matters — seen twelve times, on /checkout, by twelve people who closed the tab — on page three. Here every error is ranked by what it cost: the visitors who hit it and then finished nothing.
Grouped the way they should be
Identifiers, URLs, numbers and line numbers are stripped before grouping: a deploy moves the lines, not the error. One row per real error, not ten thousand.
“It’s back”
You mark an error as fixed. If it happens again, you know within the minute: it is the single most useful alert of all, and the only one that fires on the very first occurrence.
What it costs to set up
In the browser, one attribute on the Stats tag: data-erreurs. On the server, one request from your exception handler. No SDK, no source maps to upload.
What we never keep
No IP address and no lasting identifier: the visitor is the Stats fingerprint of the day, thrown away each night. One example stack per group, occurrences for thirty days.
What it does not do
No source maps, no session replay, no distributed tracing. If you need that, Sentry does it very well. This module answers one question: which error is costing me customers today.