An exception event is one captured error. It's the only type that gets grouped: every exception gets a fingerprint, and exceptions with the same fingerprint roll up into one issue — the thing you triage, assign, resolve, and hand to Autofix.

Where it comes from

• captureException(error) — reporting a caught error yourself.
• Automatic capture: GlobalErrorIntegration (Browser) and UncaughtExceptionIntegration (Node) for uncaught errors and unhandled rejections.
• Opt-in integrations that turn other failures into exceptions: BrowserApiErrors, HttpErrors, ResourceErrors, SlowHandler.

See Capturing Errors for usage.

Payload

{
    "type": "exception",
    "timestamp": "2026-09-24T10:15:02.481Z",
    "tags": {},
    "contexts": { "environment": "production", "release": "web@1.4.2", "replay.id": "…" },
    "payload": {
        "name": "TypeError",
        "message": "Cannot read properties of undefined (reading 'total')",
        "stack": "TypeError: Cannot read properties of undefined…\n    at checkout (app.js:1:4821)",
        "breadcrumbs": [
            {
                "type": "ui.click",
                "level": "info",
                "message": "Clicked \"Pay\" button",
                "data": { "selector": "button#pay" },
                "timestamp": "2026-09-24T10:15:01.902Z"
            }
        ]
    }
}

Field	Type	Description
name	string	The error's class name — error.name (TypeError, ApiError, …).
message	string	error.message.
stack	string, optional	The raw error.stack. Minified frames are resolved against uploaded source maps when viewed.
breadcrumbs	array	The trail of events leading up to the error — the last 50 breadcrumbs recorded on the client.

Each breadcrumb has a message, a type (e.g. ui.click, navigation, http, default debug), a level (log, debug, info, success, warn, error), an optional free-form data object, and a timestamp. See Breadcrumbs.

Grouping into issues

On ingestion the exception's fingerprint is computed from the project's fingerprint template (Settings → Fingerprint). The default is:

{{event.name}}::{{event.message}}

so every TypeError with the same message lands in one issue. The template can reference any field of the event, including tags and contexts ({{event.tags.checkout.step}}, {{event.contexts.browser.name}}), and stack is also made available parsed: {{event.frames.0.function}}, {{event.frames.0.file}}, and the ready-made {{event.frames_signature}} (top 5 frames as function@file, no line/column) — see Issues for the full list and recipes.

A second setting on the same tab decides whether an exception creates/updates an issue at all (default: every exception does). Either way, the exception itself is stored, and if it carries a release context it's counted toward that release.

Filters

On top of the filters every type goes through, exceptions can be dropped by Settings → Filters:

• Error names — exact match on name.
• Error messages — case-insensitive substring match on name + message.
• Hydration errors — framework SSR hydration mismatches.
• Chunk load errors — ChunkLoadError, "Failed to fetch dynamically imported module", …

The server-side exception sample rate is rolled independently for each event.

Quota

Counts as one toward the monthly errors limit. Other types have their own limits, so a flood of logs or metrics never stops errors from being accepted.