Features · Measure

JavaScript error tracking — without shipping user data to us

Uncaught errors and unhandled promise rejections from real visits, grouped by message, page and browser. Message, file and line are sent. The stack trace is not.

Start free Performance & errors docs

No stack traces, on purpose

Stack traces routinely carry user data — URLs with tokens, form values captured in closures. Sending them would quietly contradict everything else on this site.

Grouped where it matters

By message and page to find the bug, by browser and OS to find who it hits. Often the fastest signal that a release went wrong.

Deduplicated per page

The same error fires once per page view, capped, so an error in a render loop cannot flood your quota.

Tied to the same sessions

Errors live in the same event table as everything else, so "this page is slow AND throwing" is one query, not two tools.

The evidence

Metric errors.top

SELECT json_extract(props,'$.message') AS message,
       json_extract(props,'$.path')    AS path,
       COUNT(*) AS hits, COUNT(DISTINCT session_id) AS sessions
  FROM events
 WHERE site_id = ? AND ts >= ? AND ts < ?
   AND bot_kind = '' AND name = 'error'
 GROUP BY message, path ORDER BY hits DESC LIMIT 10

No column here can contain a stack trace, because one is never collected.

What this does not do

This is error MONITORING, not a debugger. Without stack traces you get what broke, where and for whom — not the exact line in your bundle. If you need that, run a dedicated error tracker alongside; we would rather be honest than half a Sentry.