Client Error Detection: Browser Exceptions, Failed Fetches and Hydration Errors

Last verified on Nov 8, 2026.

What it catches

Client errors covers what breaks in your users' browsers and apps: JavaScript exceptions, failed fetches and hydration errors. When one shows up in a way that deserves attention, Sazabi opens an issue in your project.

The detection reads telemetry from the client, so it only sees an app after you add an SDK. There are no alert rules to write once you have.

Examples

These are examples, not output from a real project.

A release ships a cart page that assumes items is always an array. Users with an empty saved cart see a blank page, and the browser logs:

TypeError: Cannot read properties of undefined (reading 'map')
    at CartSummary (cart-summary.tsx:48:21)
    at renderWithHooks (react-dom.production.min.js:16:2)

A checkout call starts failing for one client version. The network event looks like this:

fetch POST /api/checkout -> 502 (1840 ms)

A server-rendered page ships markup that differs from what the client renders, and React logs a hydration mismatch on load. Any of the three can open an issue.

What you see in Sazabi

You get an issue in the project's Issues inbox with a stable name, a description, a severity and a status. The docs describe an issue as arriving already investigated: the agent attaches what happened, why and the evidence. When the SDK sends W3C trace context with a request, the agent can line up the browser event with the backend work it triggered, so a failed fetch leads to the server logs behind it.

The usual actions apply: open the issue thread and ask follow-ups, resolve, ignore or mute it, or hand it to Claude Code, Codex, Cursor or Devin to fix in your repository. A repeat of the same problem while an issue is open or ignored is added to that issue rather than opening a second one.

Notifications follow your routing. Issue triggered goes to your in-app feed by default, and a shared Slack or Microsoft Teams channel gets it once a delivery rule names that channel. Rules can filter by severity, component or owning team.

What you need

You need browser or app telemetry in a production project. The ways the docs describe:

• The Sazabi browser SDK. Install @sazabi/browser, import its register entry first in your app and call init() with your intake URL and a service name. It captures uncaught exceptions and unhandled promise rejections with stack traces, mirrors console.error and console.warn, and records fetch and XHR calls with method, status and duration. See the Sazabi Browser SDK integration.
• The Sazabi React Native SDK. @sazabi/react-native is an early preview. It captures errors that reach the global handler, errors thrown while React renders inside <SazabiRoot>, and unhandled rejections on Hermes.
• An existing Sentry SDK. You can point it at a Sazabi DSN and keep sending to Sentry too. See Sentry.

The intake URL carries a write-only public key, so it is safe in a bundle.

What it does not cover

Client errors is about failures that surface as errors or failed requests. It does not cover:

• Native mobile crashes and ANRs. The React Native SDK sees the JavaScript side only.
• Session replay recordings and Core Web Vitals, which the browser SDK does not capture.
• A page that renders the wrong thing without throwing anything.
• Apps with no SDK or forwarded client telemetry.

Errors on the server side belong to a different detection: see new error detection.

Issues Sazabi detects are metered, so check pricing. The category view is frontend breakage. For general background, read the client errors guide.