Crash reporting

Crash reporting is on by default — unlike replay and body capture, the payload is data the SDK already holds (the exception plus the breadcrumb trail), fully redacted. It is a client veto, so you can switch it off:

<TraceItXProvider config={{ apiKey: 'txx_live_…', crashReporting: { disabled: true } }}>

What is caught

On the web, two mechanisms:

Report a caught exception

Inside a component, use the hook:

const { captureException } = useTraceItX();

async function save() {
  try {
    await saveCart();
  } catch (error) {
    captureException(error);
  }
}

Outside a component, import captureException from @traceitx/react. It routes to the mounted provider and is a no-op before mount and after unmount.

The signature is captureException(error: unknown): void. It reports without opening UI and reuses redaction, user context, breadcrumbs, and the outbox. Returning does not confirm server receipt; delivery uses the existing retries. Both disabled and crashReporting.disabled suppress capture, as does kill().

Explicit errors use mechanism: 'captureException', handled: true, and fatal: false. Global errors use handled: false and fatal: false because an unhandled browser error does not imply process termination. Older SDK reports may omit fatal.

Set appVersion and appBuild in the provider config to identify the release and exact deployed build. appBuild appears in context.app.build for errors and user-filed reports. Source-map processing is not available yet.

What arrives

An unattended report is an ordinary envelope with top-level source set to error instead of manual — a web page survives an uncaught error, so the web SDKs never send crash — plus a payload.crash block:

{
  "exceptionType": "TypeError",
  "message": "cart.lines is undefined",
  "frames": [
    {
      "raw": "at Cart (cart.tsx:42:11)",
      "file": "cart.tsx",
      "function": "Cart",
      "line": 42,
      "col": 11
    }
  ],
  "mechanism": "onerror",
  "handled": false,
  "fatal": false,
  "occurredAt": "2026-06-15T11:59:58.400Z",
  "fingerprint": "9f2c1ab30d84e177"
}

Frames are raw — symbolication is not in v1, so a minified bundle produces minified frames. Keep your source maps; mapping happens on your side for now.

mechanism is a plain string, not an enum, so v2 can add values without older receivers rejecting reports. Treat unknown values as opaque.

Grouping

fingerprint is 16 hex characters computed on the client from the exception type and the top frames. It is a heuristic, deliberately — it means grouping works with no server round-trip and no symbolication step. Two crashes sharing a fingerprint are the same bug often enough to be useful for triage; treat it as a strong hint, not an identity.

Duplicate reports and limits

The same error object is reported once per SDK instance across hook, top-level, and global capture. The first accepted capture determines classification. If you report a caught error and rethrow the same object, its report stays handled.

Explicit and automatic capture each accept one report per fingerprint and ten reports per SDK instance. Their allowances are independent. Distinct error objects with the same fingerprint can still be throttled, so counts describe received reports rather than every failure. Transport retries preserve the report ID and do not add server occurrences.

What comes with it

An error report has a title generated from the exception and an empty description. It includes what the SDK already had in memory: the breadcrumb trail leading to the throw, with the console and network entries on it, plus the route, device and app. There is no screenshot and no replay — nothing was frozen, because nobody opened the reporter. That is still the difference between a stack trace and a timeline.

React error boundaries

An error caught by a boundary is handled. Forward it explicitly from the boundary’s componentDidCatch method:

import { captureException } from '@traceitx/react';

// In your error boundary class:
componentDidCatch(error: Error) {
  captureException(error);
}