--- title: Errors description: 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 | Source | Level | | -------------------------------------------------------------------- | ------------------------------------------------------ | | An uncaught exception, reported by the [SDK](/sdk) | Fatal, unhandled | | `captureException(error)` from the SDK | Error, handled | | A span event named `exception` (see [OpenTelemetry](/opentelemetry)) | Error | | A log record with `exception.type` or `exception.stacktrace` | Fatal or Error from the log severity, Warning below it | ## 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: ```ts 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. | Key | Matches | | ------------- | ------------------------------------------------------------------------------------------------- | | `message` | Part of the error type or message. | | `status` | `unresolved`, `regressed`, `resolved`, `archived`, `ignored`. Defaults to `unresolved,regressed`. | | `level` | `fatal`, `error`, `warn`. | | `handled` | `handled`, `unhandled`. | | `release` | Release versions. | | `environment` | Environment names. | **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 | Status | Meaning | New events | | -------------- | ------------------------------------- | ------------------------------------ | | **Unresolved** | A new error, or one you reopened. | Recorded. | | **Regressed** | A resolved error that happened again. | Recorded. | | **Resolved** | You fixed it. | The next one turns it **Regressed**. | | **Archived** | Hidden from the default list. | Recorded; it stays archived. | | **Ignored** | Hidden from the default list. | Dropped. | New and regressed errors send the `error.created` and `error.regressed` [webhooks](/webhooks) and can fire [alerts](/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](/organization) records each change. | Key | Action | | --------- | ------------------------ | | `R` | Resolve or reopen | | `A` | Archive | | `Shift+I` | Ignore | | `J` / `K` | Older / newer occurrence | | `L` | Latest occurrence | | `U` | Back to the list | | `Shift+C` | Copy link | | `?` | All shortcuts | ## 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](/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.