Error Tracking

Coverage

• The four error-capture surfaces every application has, whether by design or accident: component-level boundaries, route-level fallbacks, application-global crash handler, and manual reporting from non-UI code paths
• The centralized-wrapper pattern: a thin module (reportError, reportMessage, addBreadcrumb, setUser, clearUser, isErrorTrackingEnabled) that sits between application code and the tracker SDK
• PII sanitization before any external send: a sanitizePII() pass over every payload, the rule that internal IDs are sent and email / name / phone are not, and the verification that wrapper-time sanitization is the actual scrubber (not the tracker SDK's beforeSend, which is a backstop at best)
• Environment-aware gating: dev mode emits to a local logger, production emits to the tracker; the gate is a single function so testing is trivial
• User context: setting and clearing userId, orgId, role (or equivalent) at session boundaries; the object signature versus positional-arg trap
• Error breadcrumbs: how to add navigation, network, and state context to events without leaking sensitive data
• Diagnostic discipline: the question "does this layer actually report, or does it only log?" — most route-level fallbacks log locally and never reach the tracker unless wired up explicitly
• Catastrophic-failure path: app-global handler bypasses the wrapper and goes straight to the SDK because the wrapper itself may have failed

Philosophy

Most production applications develop an error-tracking architecture by accident, one try/catch at a time. The accumulated result is unprincipled: some errors reach the tracker with full PII, some are silently swallowed, some are double-reported (once by the boundary, once by the catch), and the dev-prod gating is per-call instead of central. The first time someone has to audit it — usually after a customer reports their email appearing in a third-party error dashboard — the cost of repair is enormous because every call site has to be revisited.

The discipline is to centralize. Application code never imports the tracker SDK directly; it imports a thin wrapper module. The wrapper owns three concerns: sanitization, environment gating, and signature stability. Sanitization runs on every payload before any external call. Environment gating decides whether the call goes to a local logger or to the tracker SDK. Signature stability means the wrapper's API does not change when the underlying tracker is swapped — application code is insulated from vendor decisions.