Error Tracking

​

What it does

Error Tracking captures crashes and exceptions from your app and turns them into actionable issues in your dashboard — without you having to build your own crash-reporting pipeline.

• Automatic capture. Once the SDK is initialized, uncaught errors are reported without any extra code on your part.
• Manual reporting. Catch an exception yourself and send it with extra context — a bugType, a bugSeverity, and arbitrary metadata (user ID, the action being performed, anything else useful for debugging).
• Device and app context on every report. Device model, OS/version, architecture, timezone, country, and your app’s version/build number are attached automatically — you don’t have to collect and send them yourself.
• AI-assisted summaries. Bug details in the dashboard include an AI summary panel that helps you understand what went wrong faster.
• Assign and discuss. Assign a bug to a teammate and comment on it directly in the dashboard as you work through a fix.

​

Classification

Reports carry a bugType (e.g. crash, networkError, uiBug, performance) and a bugSeverity (critical down to low) so you can triage what matters first. See your framework’s guide for the full list of values.

​

How errors are grouped into issues

Lerix doesn’t create a new issue for every report. Repeated reports of the same error are grouped into one issue, so a bug that fires 10,000 times shows up once, with a count. Two things decide which issue a report belongs to:

• The first line of the error message, with variable parts masked. Numbers, UUIDs, hex IDs, email addresses and URLs are replaced before comparing. Order 1234 not found and Order 5678 not found are the same issue. Error codes such as #441 or PGRST202 are kept, so different codes stay different issues.
• The first stack frame that belongs to your app. Frames from the Lerix SDK, the runtime and your dependencies (for example node_modules, package:flutter or System.*) are skipped. Only the function and file name are used. Line and column numbers and bundler content hashes (like chunk-Cr8GYWvZ.js) are ignored.

Because line numbers and bundle hashes don’t count, a web error stays the same issue across deploys instead of starting over with every build. Grouping happens on the Lerix server, so it applies to every SDK version automatically.

​

What the dashboard shows for each issue

The issue list is sorted by Last seen, so whatever is happening right now is at the top.

​

Status, regressions and ignored issues

Status, severity and assignee belong to the whole issue, not to a single report.

• Regressions. If an issue you marked resolved or closed happens again, it is reopened automatically and project members get the status-change email.
• Ignored issues. An ignored issue keeps counting occurrences, but it stays ignored and sends no notifications. It is hidden from the default list. Use the Ignored filter to see it.

​

Built-in noise rules

The server filters a few kinds of reports that never point at a bug in your code. These rules apply to every project and every SDK version: The backend SDKs (NestJS, Python and ASP.NET Core) also don’t report HTTP 4xx exceptions by default. Those are client mistakes, not server bugs.

​

Filtering errors in your app

For noise specific to your app, every SDK takes two options when you initialize it:

• An ignore list. A string drops any error whose message contains it, ignoring case. A regular expression drops any error whose message it matches. Blank strings are skipped.
• A before-send callback. It receives the error event and returns it to send it, returns a changed copy (for example with a token redacted), or returns nothing (null, nil or None) to drop it.

The ignore list runs first, and the callback only sees what’s left. If the callback throws, the original event is sent and the exception never reaches your app. Both match against the issue title, which includes the error class, for example TypeError: boom. The React, Next.js and Angular SDKs get these options from @lerix-dev/lerix-core 1.3.0. The SDKs ship no built-in ignore patterns of their own. Common noise is handled by the server rules above.

​

Source maps

Production web builds are minified, so a browser stack trace points at positions in bundled chunks, like onConnMessage@https://app.com/chunk-Cr8GYWvZ.js:10:14780, instead of your code. Upload your build’s source maps with the Lerix CLI and new errors show the original file, line and function (for example src/app/chat/chat.page.ts:142) with the surrounding code. The maps are uploaded privately and removed from your build output before you deploy, so your source is never served publicly. The AI assistant, GitHub issues and the MCP server all see the readable stack too. Backend SDKs need no upload. NestJS reads the .js.map files that nest build writes (see TypeScript file and line numbers), and ASP.NET Core reads the debug info in your build (see File and line numbers).

​

Get started

More framework guides are on the way — see the Getting Started page for current platform availability.