Skip to main content

​
crewship telemetry

Manages the crash-reporting consent state stored in the local app_settings table. The running server picks up changes on the next start.
Default for v0.1 beta: ENABLED. First crewship start on a fresh DB writes opt-in=true and starts the Sentry client. Documented in full in Telemetry — Default by build flavour. The default-on stance reverts to opt-in for v1.0 GA.

​
crewship telemetry on

on and off change the local database and require the writing server to be stopped. They acquire exclusive ownership before initializing or updating it; a live server cannot be bypassed by a local consent change. Read-only status inspection remains available while the server runs. Writes telemetry_opt_in = "1" to app_settings and generates an anonymous install ID (random 32-hex) if one doesn’t exist yet.
The install ID is stable across opt-in/opt-out cycles — re-rolling it would make crash grouping unstable in the maintainer’s Sentry view.

​
crewship telemetry off

Writes telemetry_opt_in = "0". The off-state is sticky: even if the v0.1 beta default-on logic would normally enable on fresh boot, an explicit “0” wins. This is what makes opt-out reliable.
The install ID is preserved (just not used). Opt back in later and you’ll keep the same ID — past crashes still group with future ones.

​
crewship telemetry status

Shows the resolved state without changing anything.
Consent is a row in a database, so the answer is only as meaningful as the file it came from. The database line names that file and how it was resolved — DATABASE_URL → CREWSHIP_DATA_DIR → ~/.crewship, the same order the server uses. It prints on every branch, including “not yet configured”, where which file is missing is the useful half of the answer.
Until #2109 this command ignored DATABASE_URL and always read ~/.crewship/crewship.db, so on a host whose crewshipd runs with its own database — every development clone uses file:./crewship.db — it reported a consent row the running server had never seen.
Or when off:
Or when no explicit choice has been recorded yet (never-booted DB, or a stable build that hasn’t been opted in). The message reflects the build’s default — prerelease/dev builds settle to ENABLED on the next crewship start, stable builds stay DISABLED until you opt in:
The endpoint line shows where events would route plus why:
  • vendor default (compiled in) — DSN baked into the binary at release time via -X .../crashreport.DSN=... ldflag. Routes to the maintainer’s Sentry project (crewship-backend).
  • CREWSHIP_SENTRY_DSN env override — operator set the env var to redirect events to their own Sentry instance. See Telemetry — Routing override.

​
Routing override (don’t ship to maintainer)

For enterprise self-hosters, regulated environments, or anyone who’d rather pay their own Sentry quota:
crashreport.ResolveDSN() prefers the env value over the ldflag-baked default. crewship telemetry status will reflect the override in the endpoint line.

​
What gets sent (recap)

Full details and the implementation reference in Telemetry — What gets sent and the client-side filter in internal/crashreport/sentry_adapter.go::scrubEvent.

​
Programmatic opt-out (CI / scripts)

To pre-set the consent before the first crewship start — useful when provisioning Crewship from a config-management tool that doesn’t want the beta default-on:
crewship telemetry opens the DB at the same path crewship start would and applies the v88 migration (app_settings) on first run, so the consent setting works even on a never-started fresh install.
  • Telemetry guide — privacy posture, what’s sent, server-side scrubbing rules, full routing-override flow.
  • crewship doctor — shows the same telemetry state alongside other system checks.
  • crewship start — boot flow that initializes the Sentry client based on consent.