0031. The platform reports its own errors, panels' included, to the instance's errors service
Status: accepted, 2026-10-21.
Context
When a panel crashes or throws, nobody hears of it: the error stays in one browser's console. Services'
panics are logged without a stack. The platform has an error tracker that speaks the Sentry protocol
and watches users' apps and sites, but not the platform itself. Phones make this worse: a phone's
browser has no developer tools at hand, and most phone problems are only seen there.
Decision
- errors keeps one project owned by the instance, the platform project, visible to superusers only and
outside every team's limits. errorsd makes it; xvii-node hands its DSN to every service as
ERRORS_DSN, and home's public catalog hands it to panels, like any DSN a browser uses.
- Services report panics and unexpected errors to it through kit (the observability design).
- Panels catch render errors with an error boundary and listen for uncaught errors and rejected
promises. They send a small Sentry-format event straight to the platform project with the release
(
<service>@<version>) and the person's id, at most ten a page. errors takes the platform project's
browser events only from the instance's own origins.
- What a report may hold: the error and its stack, the route with ids folded, the viewport, pointer,
language, theme and display mode, and the last navigations and API calls (method, path, status,
request id). Never query strings, page text, form values, browser storage, names or e-mail
addresses.
Consequences
- A crash on a phone shows up in errors within seconds, with the release that caused it.
- errors becomes a soft dependency: without it nothing is reported, and nothing breaks.
- The DSN is public, as browser DSNs are; junk is bounded by errors' per-project rate limit and the
origin check.
- errorsd doesn't report to itself, so a broken errors can't feed itself.
- Stacks point into built files until errors symbolicates panel releases from their source maps.