Detection
Detection

Browser-Specific Error Detection: An Issue When Only One Segment Is Affected

By Sazabi Team

Last verified on Nov 10, 2026.

What it catches

Averages protect most of your users and hide a few of them. When only Safari users fail checkout, when one app version crashes on launch or when a single region cannot reach a dependency, the overall numbers barely move. Support finds out before your charts do.

Segment-specific behavior is the check that asks the question per slice. It fires when a problem is concentrated in one browser, operating system, app version, region or customer, even if the rest of your traffic is fine. It also tells you the slice, which is the hardest part of diagnosing these.

What it tends to find:

  • A CSS or JavaScript feature one browser version does not support.
  • A mobile release with a crash on one operating system version.
  • A regional edge or DNS problem that affects one geography.
  • A customer whose configuration hits an untested path.
  • A plan tier with a permission that was removed by mistake.

Example: checkout fails on one browser version

This is an example, not output from a real project. Your frontend logs each checkout submit with the browser. The error rate is low everywhere except one version:

2026-11-08T17:41:09Z ERROR web checkout_submit_failed browser=Safari browser_version=18 error="TypeError: undefined is not a function" route=/checkout
2026-11-08T17:41:15Z INFO web checkout_submit_succeeded browser=Chrome browser_version=130 route=/checkout
2026-11-08T17:41:22Z ERROR web checkout_submit_failed browser=Safari browser_version=18 error="TypeError: undefined is not a function" route=/checkout
2026-11-08T17:41:30Z INFO web checkout_submit_succeeded browser=Firefox browser_version=132 route=/checkout

Total failures look like a small blip. Within the Safari 18 slice almost every attempt fails. Sazabi opens an issue. An example of what it could say:

  • Name: Checkout fails for Safari 18 users only
  • Description: checkout_submit_failed is concentrated in browser=Safari version 18 with the same TypeError. Other browsers complete checkout at their usual rate.
  • Severity: high

The browser and version are in the title. The next step is to reproduce in that browser, not to scan stack traces from every user.

How Sazabi sets it up

You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time, including for the fields in your logs that segment your users and traffic. In plain words: "Tell me when the share of failed checkouts for any one browser goes above its usual level."

Judging each segment on its own is the point. Safari 18 can fire while Chrome stays quiet, and a small affected group does not disappear into the average. The agent writes, backtests and maintains these sensors.

A detection records a signal and starts an investigation, which opens an issue when the problem is real.

What you see and how you get told

The issue names the segment and the failure it carries, with evidence from affected events. You can ask the agent follow-ups, such as whether the same segment is affected elsewhere, or use sazabi issues agent-prompt to give the fix to a coding agent. Issue triggered goes to the in-app feed, and delivery rules route by severity, component or owning team to a shared Slack or Microsoft Teams channel. sazabi signals list --type sensor shows each detection.

What you need

Events that carry the segment as a field, plus the error or outcome. For browsers and apps, Sazabi's frontend and mobile SDKs cover errors and sessions, as described in frontend breakage and client errors. Backend logs work too if they include region, tenant or version. See OpenTelemetry and AWS for connecting sources.

What it does not cover

  • Segments that are not in the logs. Without a browser field, no check can split by browser.
  • Users who never produced an event.
  • Failures spread evenly across all segments. Those are ordinary errors, covered under new error detection.
  • Individual user complaints with no common trait.

For the wider view, read frontend breakage. Issues are metered; see pricing.

What Sazabi detects today

There are no monitors or alert rules to write: the Sazabi agent automatically sets up sensors for your project and maintains them over time. Sazabi opens an issue when one fires.

  • Segment-specific behavior: Only one browser, OS, app version, region or customer is affected. Example: Only Safari 18 users fail checkout.

Frequently Asked Questions

Which segments can it find?

Any field your events carry that splits users: browser, operating system, app version, region, plan or customer. The agent reads your logs to see which of these exist.

Why not just look at the overall error rate?

A problem on one browser can be a small share of total traffic, so the overall rate hardly moves. Checking per segment keeps a small affected group from disappearing into the average.

Does it need user-level data?

No. It needs a segment field on the event, such as a browser name or app version. It does not need names or emails, and you should leave those out of the logs.

Can it flag a single customer?

If events carry a customer or tenant identifier, yes. Each customer is judged on its own.

Sources

  1. Issue contents, severity levels, recurrence handling, response actions (accessed Nov 8, 2026)
  2. Issue triggered notification, delivery rules by severity, component and owning team (accessed Nov 8, 2026)
  3. Signals and managed investigation, issues arrive already investigated (accessed Nov 8, 2026)
  4. sazabi signals list with the sensor type filter (accessed Nov 8, 2026)