Errors

How OpenPerf groups errors, and how to find, read and triage them.

Errors lists error groups. A group collects every event of one error in one project, so a bug that fires a thousand times is one row.

What becomes an error

Grouping

Events join one group when they share the error type and the top of the stack trace. Line and column numbers, UUIDs, hex values, file hashes and numbers are ignored, so a new deploy doesn’t split a group. An event without a stack trace groups by type and message.

To group events yourself, give them the same fingerprint:

captureException(error, { fingerprint: "checkout-payment-timeout" });

Over OpenTelemetry, set the openperf.error.fingerprint attribute.

Find errors

The filter bar has a project picker, a search box and a time range. The range defaults to the last 7 days and spans at most 90.

The search box takes key:value filters. Separate values with commas and quote values with spaces: status:resolved,archived level:fatal message:"connection reset". Words without a key are not applied.

Sorted by orders the list by Events, Users, Trending, Last seen or First seen. A New badge marks errors first seen inside the selected range. Counts cover the selected range only.

Statuses

New and regressed errors send the error.created and error.regressed webhooks and can fire alerts.

Triage

• In the list, select rows to open the action bar. Resolve is the main action, or Reopen when every selected error is closed. Archive and Ignore sit under More actions and ask for confirmation.
• On an error, change the status from the Properties section or with a shortcut.

Any member of the organization can change a status. The audit log records each change.

Error page

The page shows one occurrence at a time, the latest in the time range by default.

• Occurrences: events over time, with release markers. Click a bar to open an event from that bucket.
• The occurrence bar shows when it happened, its position such as “3 of 120 events”, and tags: environment, release, level, handled, transaction, runtime, browser, OS, device and user.
• Stack trace: app frames, with library frames folded. Frames from node_modules/, node:, internal/, site-packages/, dist-packages/ and /gems/ count as library frames. Show all frames unfolds them and Raw shows the original text.
• Breadcrumbs: what led up to the error. The browser SDK records clicks, navigations and console messages; addBreadcrumb adds your own.
• Trace and Logs: the trace the error happened in and its logs, when the event carries a trace ID. Open trace and Open in Logs jump to them.
• All attributes: every attribute of the event and its resource.

The sidebar shows the status, level and handled state, the project, a linked Linear issue, events in the range against the period before, users, when the error was first and last seen with links to those releases, and its environments.

Minified browser stack traces become readable when the release’s source maps are uploaded before the errors arrive; see Releases. Events received earlier stay minified.

Suspect commit

With the GitHub integration and a code mapping for the project, the stack trace shows a Suspect commit: the latest commit before the error was first seen that touched one of its app frames. Add the mapping under Settings → Integrations → GitHub:

• Stack root: the start of file paths in stack traces, such as /app/ or webpack://app/. Empty matches every path.
• Source root: the repository folder it points to. Empty means the repository root.

The lookup uses the commit of the error’s release when OpenPerf knows it, otherwise the repository’s default branch.

Linear issues

Once an owner or admin connects Linear under Settings → Integrations, More actions → Create issue on an error opens a Linear issue with a title, description, workspace and team. The issue links back to the error and shows in its sidebar. Unlink issue removes the link without touching the issue.