Skip to main content

​
Error Tracking (Sentry)

Two independent things on one card:
  • Error capture — the browser SDK in the admin UI, the Node SDK in the backend, and a separate browser SDK in the operator console, each with its own DSN.
  • The operator console’s issues feed — recent unresolved issues, read with an organization auth token.
Either half works without the other. What is captured, what is deliberately not (no session replay, no PII, no cookies or bodies) and how source maps work is documented in Error tracking; this page is the setup. Scope: Global defaults only — errors are platform-wide.

​
1. In Sentry

​
Projects and DSNs

  1. Create one project per SDK: a React project for the admin UI, a Node.js project for the backend, and — if you run it — a React project for the operator console. One project for everything works, but separate projects give cleaner releases, source maps and access control. The console gets its own on purpose: its events identify operators, not tenants, so it can be switched on independently.
  2. For each project: Settings → Client Keys (DSN) → copy the DSN (https://<key>@o<org>.ingest.<region>.sentry.io/<project>).
A DSN identifies a project; it is not a secret and is delivered to browsers by design.

​
Organization token (issues feed, optional)

  1. Organization Settings → Auth Tokens → Create New Token with exactly org:read, project:read and event:read. Read-only — the console never resolves or mutes issues. Use an organization token, not a personal user token that dies with the account.
  2. Copy it (sntrys_…) — shown once.
  3. Note your organization slug: the segment after sentry.io/organizations/ in any Sentry URL.

​
2. Enter it in KnoxCall

Settings → Integrations → Global defaults → Error tracking (Sentry) → Configure: Any subset is a valid save: DSNs only, token only, or all of it. Save credentials.

​
3. Verify

  • Backend DSN: applies immediately. The next 5xx — or any unhandled exception — appears in the backend project.
  • Browser DSNs: delivered to the SPA at page load, so reload the admin UI; a React render error or an unhandled rejection appears in the browser project.
  • Issues feed: the operator console’s Test connection reads the organization with the stored token. A 403/404 there almost always means the slug is wrong or the token lacks org:read.

​
Things that bite

  • The environment wins for the DSNs. SENTRY_DSN, SENTRY_DSN_BACKEND and SENTRY_DSN_CONSOLE override the stored values on a self-hosted host. The organization token has no environment form.
  • Scheduled jobs, workflow workers and the standalone proxy read the backend DSN from the environment only — deliberately, because the database being down is exactly when an error report matters. A DSN saved only on this card reaches the API process; set SENTRY_DSN_BACKEND to cover every process.
  • Disabling the row switches both halves off — capture and the issues feed.
  • Warn-level logs are off by default. Set SENTRY_LOGS=1 to ship warn and error log lines alongside exceptions; log ingest is billed by volume, so it is never enabled as a side effect of setting a DSN.
  • Minified browser stacks. Source maps are uploaded at build time with SENTRY_ORG, SENTRY_PROJECT and SENTRY_AUTH_TOKEN on the build machine — not runtime configuration.
  • Sub-processor. On the hosted service a DSN makes Sentry a sub-processor; self-hosted, the data goes to your project. Review your disclosures before enabling it in production.