Error tracking for browser and server apps
An exception is more useful when you can see the release, the preceding interactions and the people affected. SaaS Pro Max brings browser and server errors into the same console as your analytics, so triage can start with impact rather than a raw error count.
| Issue | Events | Users | Status |
|---|---|---|---|
| TypeError Cannot read properties of undefined (reading 'plan')app/checkout/summary.tsx in PlanSummary | 84 | 61 | unresolved |
| FetchError POST /api/billing/session returned 502lib/billing/session.ts in createSession | 31 | 27 | investigating |
| ChunkLoadError Loading chunk 42 failednext/dist/client/route-loader.js | 12 | 12 | resolved |
Turn repeated exceptions into one issue
Errors are grouped by a fingerprint based on the error and stack context. Use an explicit SDK fingerprint or operator grouping rules when the default does not fit your application. Repeated occurrences stay attached to an issue, while release and affected-user context help you decide what to investigate first.
Get back to the code that failed
Stack frames distinguish application code from vendor frames. Upload source maps for readable browser stacks, and inspect breadcrumbs for the navigation, clicks, requests and console events leading up to an exception. When replay is configured and the recording covers the error, continue at the matching playback timestamp.
Track the issue through a release
Resolve or ignore an issue, leave investigation context and follow release health. A new occurrence can identify a regression after resolution. Changes to issue state are permission-checked and audited, so the team can see which action was taken while keeping production and staging investigations separate.
Put it to work.
Start with one application and verify the data you send.
- Install a browser, React or server SDK and configure error capture for your application.
- Attach release identifiers and upload matching build artifacts or source maps.
- Triage grouped issues, inspect the affected journey and follow recurrence after a fix.
Readable stacks depend on matching source maps and release information. Replay and person details require their own collection settings and permissions. Scrub sensitive data before sending exceptions or breadcrumbs.
Module availability and retention vary by plan. Compare plans and limits.