Browser errors
Built and checked locally on 8 November 2026 (SHIF-43; standard names, network noise and the source-map secret SHIF-44) · not deployed: production and dev have no values yet, so nothing is reported from there
The app, the admin app and the website can report errors that happen in a person's browser, and the app and the website also errors while their server prepares a page, to our own error tracker (GlitchTip, which speaks the Sentry protocol), but only when a build is given that application's key and one of three environment names. Without them, reporting is off and nothing is sent.
Errors are sent so that we can fix them, never so that we can read what people wrote: no chat text, no form fields, no email, no query string, and the user by id only.
Until now an error in the browser was seen by nobody but the person in front of it. The API's errors are a separate task (SHIF-42) and are not on this page.
What is sent and what is not
| Sent | Not sent |
|---|---|
| Errors inside a screen (a component) | Refusals the person was already shown: any 4xx answer of the API (wrong password, a conflict, a missing page) |
| Unhandled errors and unhandled promise rejections | Requests that were cancelled (AbortError), for example by leaving a page; requests that got no answer at all, and the browser's own network errors ("Failed to fetch", "Load failed" and the like) |
| Errors while switching pages and while loading a part of the application | Errors thrown by browser extensions (chrome-extension://, moz-extension:// and the like) |
| A 5xx answer of the API that nothing caught | — |
Before an error is sent it is cleaned: request bodies, cookies and every header except the browser's user agent are removed; the query string and fragment are cut from every address; emails and tokens in messages are replaced; console output, what was typed, the values on a screen (component props) and form state are not attached; the user is reduced to an id (set when someone signs in to the app or the admin app); the server's machine name is not sent; no source code lines or variable values from the stack are attached. There are no sessions, no performance tracing (tracesSampleRate: 0), no screen recording, and no tracing headers are added to the calls to the API: GlitchTip has no sessions, and only errors are wanted.
The app and the website prepare each page on their server first (server rendering); an error in that step is reported too, by the same rules: from the request only the path and the browser's user agent are kept, never its body, cookies or other headers. Server answers in the 4xx range (a missing page, say) are not sent. The admin app is drawn entirely in the browser; its server only hands out the empty page, so there is nothing of its own to report there.
Turning it on
Each application has its own key and reads the deployment's names; they are listed in its .env.example (app/, admin/, website/) and, for all four parts with the API, in Error tracking (GlitchTip). The values are not in the repository.
| Variable | When | What |
|---|---|---|
APP_SENTRY_DSN, ADMIN_SENTRY_DSN, WEBSITE_SENTRY_DSN | build; the app and the website also at start | The application's key in GlitchTip, for the browser and the server alike. Empty: reporting is off and the error library is not even started. The Dockerfile hands it to Nuxt as NUXT_PUBLIC_SENTRY_DSN. |
SENTRY_ENVIRONMENT | build and start | Exactly prod, dev or local. Empty or anything else also turns reporting off; the library's default name, "production", is never sent. GlitchTip keeps every environment name it has seen forever, so there are only these three. A local run (make dev, ./orca/run.sh) always sets local. |
SENTRY_RELEASE | build | The git commit the build is made from. When it is empty, the build takes the commit from git if a repository is there (locally); the Docker build has none, so there it must be passed in, or the error carries no release. |
SENTRY_AUTH_TOKEN | build, secret | Uploads the source maps (which turn minified code back into readable lines) to GlitchTip. Only ever a BuildKit secret (id=SENTRY_AUTH_TOKEN), never a build argument, so it is in neither the image nor its metadata. Without it nothing is uploaded and the build does not fail. With it, SENTRY_ORG (dreamvention) and APP_/ADMIN_/WEBSITE_SENTRY_PROJECT (shiffty-app, shiffty-admin, shiffty-website) are required. SENTRY_URL points at our GlitchTip by default. |
Source maps are made for the browser code but never served: the build removes every .map file from what the server hands out, and the code carries no link to them. A failed upload is printed in the build log and does not stop the build.
How it was checked
On 8 November 2026, in a working copy: unit tests of the filters and of the cleaning in each of the three applications, including the real error library for the browser and for the server (a 5xx goes, a 4xx and a cancelled request do not, no session is sent, the request is cleaned, and with no key nothing is sent at all); production builds of all three with no .map file in the served output; a built server that failed while rendering a page, its error caught by a local stand-in for GlitchTip and found clean; and test errors with the environment local and a tag naming the task sent to GlitchTip — one from the browser for each application and one from the server render of the app and of the website — all of them listed there. Again on 8 November 2026 for SHIF-44, in a working copy with the environment local and the tag task=SHIF-44: in the browser of each application an unhandled error and an unhandled rejection went to GlitchTip (answer 200), while a failed request to an unreachable address, a cancelled request, a 404 and a request with no answer did not; a wrong password on the sign-in page showed its message and sent nothing; the query string of the page (?token=…) and a line written to the console were not in the events, and the admin app's event carried the administrator's id and nothing else about them. The same two errors from the server half of the app and the website, with the real error library under Node, went too, with no machine name. A Docker build of the app with a token as a build secret and an unreachable GlitchTip passed, its failed upload printed; the token was found neither in the build log, nor in the image's history, nor in its files. Nothing was checked in production or dev, where the values are not set yet.
Where to go next
- DevOps overview: what is deployed and what is not.
- Architecture: the applications this page is about.