> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Error Tracking (Sentry)

> Send KnoxCall's admin-UI, backend and operator-console exceptions to Sentry — the projects to create, which DSN goes in which field, the read-only organization token for the console's issues feed, and the environment-precedence rule.

# 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](/monitoring/opentelemetry#error-tracking-sentry); 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*:

| Field                                      | Value                                                                 |
| ------------------------------------------ | --------------------------------------------------------------------- |
| **Sentry DSN — browser (admin UI errors)** | The admin-UI project's DSN                                            |
| **Sentry DSN — server (backend errors)**   | The backend project's DSN                                             |
| **Sentry DSN — operator console**          | The console project's DSN (leave blank if you do not run the console) |
| **Organization slug** *(optional)*         | e.g. `my-org`                                                         |
| **Organization auth token** *(optional)*   | `sntrys_…`                                                            |

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.

## Related

* [Error tracking](/monitoring/opentelemetry#error-tracking-sentry) — capture semantics, privacy, source maps
* [Sentry as an OTLP backend](/monitoring/opentelemetry#sentry-as-an-otlp-backend)