Frontend Breakage Detection: Issues When Your Web or Mobile UI Breaks

Last verified on Nov 10, 2026.

What it catches

Frontend breakage is what users see when pages, screens or client code crash, fail to load or behave wrong. Sazabi covers it with three live signals:

• Client errors reports JavaScript exceptions, failed fetches and hydration errors from your web or React Native app. It comes from new-error detection. See client error detection.
• Web vitals regression fires when page load and responsiveness get worse. The Sazabi agent writes it for your project.
• Segment-specific behavior fires when only one browser, OS, app version, region or customer is affected. The agent writes it too.

The agent sets up sensors for the last two, and there are no alert rules to write. A sensor can only watch measurements that reach your logs. The browser SDK does not capture Core Web Vitals, so a web vitals sensor depends on page-load numbers arriving from somewhere else in your telemetry.

Examples

These are examples, not output from a real project.

• After a release, the pricing page throws TypeError: structuredClone is not a function for users on an older embedded browser, and the page never finishes loading.
• A search box calls /api/search and the call returns 500 for every request from the mobile web layout.
• A server-rendered article page ships markup that does not match what the client renders, and the console reports a hydration mismatch.

The first two share a shape that a plain error count misses. The errors are a small share of all sessions, but they are all in one segment:

TypeError: structuredClone is not a function
    at PricingToggle (pricing-toggle.tsx:22:9)
    userAgent=EmbeddedWebView/9 appVersion=4.12.0

A segment-specific sensor asks whether failures are concentrated in one app version compared with the rest. When they are, the issue names the version instead of reporting a vague rise in errors.

How it reaches you

Each result becomes an issue with a stable name, a description, a severity from low to critical, an optional component and a status. It arrives already investigated, with the agent's account of what happened, why and the evidence. For a sensor, a firing records a signal and starts that investigation. If the investigation finds nothing worth your time, it closes without an issue.

The browser SDK sends W3C trace context on same-origin requests, so a failed fetch in the browser can be lined up with backend logs for the same request. That is often the quickest way to learn whether the bug lives in the page or behind the API.

From the issue you can ask follow-up questions in its thread, hand it to Claude Code, Codex, Cursor or Devin with the issue's prompt, or resolve, ignore or mute it. Issue triggered reaches your in-app feed by default. A delivery rule can send it to a shared Slack or Microsoft Teams channel and match on severity, component or owning team, which suits a frontend team that wants only its own surface.

What you need

Browser or app telemetry in a production project:

• Web: the Sazabi Browser SDK, installed as @sazabi/browser with one init() call that takes your intake URL and a service name.
• Mobile: the Sazabi React Native SDK, an early preview, for React Native and Expo apps.
• An existing Sentry SDK pointed at a Sazabi DSN, if you already run one. See Sentry.

The vendor-neutral write-up is the frontend breakage guide.

What it does not cover

• A page that renders the wrong content without throwing an error.
• 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.
• Apps with no SDK or forwarded client telemetry.

Issues Sazabi detects are metered, so check pricing.