Skip to main content
Solya uses structured logging and Sentry for error tracking, with PII kept out of error reports.

​
Logging

  • Levels — debug, info, warn, error (increasing severity). The threshold is set by the LOG_LEVEL environment variable (default info); messages below it are skipped.
  • Format — human-readable in development; JSON lines in production (one object per line) for ingestion by log tooling.
  • Context — server logs automatically include the request correlationId, userId, and organizationId when available, so you don’t repeat them.
  • Server vs client — server code uses the server logger (which forwards errors to Sentry); client/isomorphic code uses a logger whose debug/info calls are stripped in production.

​
Sentry

Sentry is initialized for the server, edge, and client runtimes. It is enabled only when a DSN is set:
  • SENTRY_DSN (server) / NEXT_PUBLIC_SENTRY_DSN (client).
  • SENTRY_ENVIRONMENT / NEXT_PUBLIC_SENTRY_ENVIRONMENT — the environment tag.
  • SENTRY_RELEASE / NEXT_PUBLIC_SENTRY_RELEASE — the release identifier.
Tracing and session replay are disabled (errors only).

​
What is and isn’t sent

  • Severity / category filtering — error-level logs go to Sentry, except low-severity and validation errors, which are treated as expected operational noise.
  • PII scrubbing — before an event is sent, event.user.email is removed. Other fields (messages, breadcrumbs, stack traces) are intentionally preserved to keep diagnostics useful; widening redaction would require dedicated tests to avoid silently dropping signal.
If you add a new field to the user context sent to Sentry, decide whether it’s PII and, if so, extend the scrubber and its tests. See the security convention for details.