Error Tracking

Most error tracking products assume “always on” is the right default. For an RMM running inside an MSP tenant boundary, that assumption is wrong. Breeze inverts it: error tracking is off by default, opt-in with a single setting, and aggressively masked so even an opted-in deployment doesn’t exfiltrate the data the platform exists to protect.

Off Until You Say Otherwise

Self-hosted Breeze deployments ship with error tracking disabled. The browser bundle doesn’t initialize the SDK, doesn’t load replay, and doesn’t open an outbound connection unless an operator turns it on. If you never enable it, no telemetry leaves your network — period.

When you do enable it, the browser starts capturing unhandled JavaScript errors, promise rejections, and an on-error session replay of the seconds leading up to the failure. Same build artifact, different behavior. No special branches, no “telemetry-free” fork to maintain.

The setting is exposed during initial setup as a clearly labeled optional step. Skip it and the feature stays off. Enable it and you confirm the masking defaults before anything ships.

Aggressive Masking Before Anything Leaves the Browser

When error tracking is on, Breeze aggressively masks text, inputs, URLs, cookies, headers, request bodies, and resource identifiers before any payload leaves the page. A replay can show that an error happened inside the patch deployment flow without revealing which org, which devices, or which patches were involved.

You get the regression signal. Tenant data stays in the tenant.

Why This Matters for MSPs

You are running software inside a customer trust boundary. Browser telemetry that quietly phones home is a compliance conversation you don’t want to have — and an incident you really don’t want to have. Breeze gives hosted operators the observability they need to catch frontend regressions, and gives self-hosted operators the option to have zero browser telemetry at all.

A typical flow on hosted Breeze: a UI release introduces a subtle handler bug that throws when a user has more than 50 saved filters. The operator sees the unhandled error, a stack trace, and a masked replay of the click that triggered it — and ships a fix before most users hit it. Customers never have to file a ticket describing something they can’t reproduce.

Configuration

Activation is a single configurable setting that points the browser at a telemetry destination. Empty means disabled. Non-empty initializes the SDK with the masking defaults above. Retention lives with the telemetry destination, not with Breeze — operators are responsible for confirming that retention aligns with their compliance posture.

If the telemetry endpoint is ever unreachable, the browser drops the events silently. The Breeze UI keeps working and the underlying error still surfaces in the browser console. Enabling error tracking can’t make Breeze less reliable.