Telemetry events — full reference

Dotvault’s anonymous usage telemetry is off by default and only sends anything if you explicitly opt in. This page is the canonical reference for every event it can send if you do. If an event isn’t on this page, it isn’t being sent.

For the shorter version, see the privacy policy. For how to turn telemetry off, see the FAQ.

Ambient metadata

Every event is tagged with:

  • Operating system — macOS version.
  • App version — the Dotvault version you’re running.
  • Locale — your system locale (e.g. en-GB).

These are captured by Aptabase automatically. No IP address is stored.

What I never send

Across every event below, Dotvault never sends:

  • Environment variable names or values
  • File names, project names, or any file paths
  • Licence keys, instance IDs, or email addresses
  • Error messages or stack traces
  • Any string you’ve typed into the app

Your .env files never leave your machine. The analytics code is walled off from your file contents by design and simply cannot see them. Everything documented below is either a closed-enum value from a fixed list, or a framework/package name from a hardcoded public registry that ships inside the app.

Usage events

These fire when you interact with Dotvault’s normal features.

Event Fires when Payload
app_started The app launches.
project_created You create a project. frameworks and packages — comma-joined names from a fixed public registry. Only names that appear in the registry can leave your machine. Also a framework_count and package_count integer.
project_opened You switch to a different project in the sidebar.
framework_detected Dotvault detects a framework in a project (one event per framework). name — a single framework name from the fixed registry (e.g. laravel, nextjs).
package_detected Dotvault detects a package in a project (one event per package). name — a single package name from the fixed registry (e.g. stripe, sentry).
env_file_created You create a new .env file. template — one of blank, framework, from_example.
snapshot_restored You restore a snapshot from the History panel.
diff_viewed You open the Diff view.
compare_viewed You open the Compare view.
git_panel_opened You open the Git panel.
clipboard_imported You import variables from the clipboard.
auto_grouped You apply auto-grouping in the editor.
sync_keys You sync keys between two files in the Diff view. mode — one of keys, keys+values.
encryption_key_set You set a Laravel encryption key on a file — by encrypting a plaintext file, unlocking an encrypted one, or rotating an existing key.
command_palette_opened You open the command palette (Cmd+K).
env_exported You open the export dialog.

Licensing events

These fire around the state of your Dotvault licence or trial. None of them contain the licence key, instance ID, email, or any raw LS API response.

Event Fires when Payload
license_trial_started Your 14-day trial begins on first launch.
license_activated You successfully activate a licence.
license_activation_failed An activation attempt fails. reason — one of limit, invalid, network.
license_deactivated You deactivate a licence from Settings.
license_validation_failed A background licence check fails. reason — one of invalid, network.
license_revoked A licence becomes inactive. cause — one of trial_ended, disabled, deactivated_remotely, clock_rollback.
license_buy_clicked You click a Buy Dotvault button. source — one of trial_banner, settings, expired_screen.

Crash reporting

Closed-enum crash event (Aptabase)

Event Fires when Payload
renderer_error The app UI hits an unexpected error. source — one of react, window_error, unhandled_rejection.

renderer_error is source-bucket only. Dotvault never sends the error message, the stack trace, the component name, the file path, or any other error detail in this event. If you want to share the full error with us for debugging, the in-app “Something went wrong” screen has a Copy details button that puts the full details on your clipboard for you to send manually — that’s always user-initiated.

Sanitised crash reports (Sentry)

In addition to the closed-enum event above, Dotvault sends a sanitised error report to Sentry when an unexpected app error occurs. These reports are gated by the same telemetry toggle — if you haven’t opted in, nothing is sent.

What a Sentry report contains:

  • Error type (e.g. TypeError, RangeError)
  • Sanitised stack trace — absolute file paths are scrubbed to relative paths (e.g. src/main/index.ts) before the report leaves your machine
  • App version and OS version

What a Sentry report never contains:

  • Environment variable names or values
  • File names or project names
  • Absolute file paths (scrubbed before transmission)
  • Any personal data or user identifiers

Sentry processes data in the EU (Frankfurt data centre). Reports are retained for 90 days.

How telemetry is delivered

Usage analytics are sent to Aptabase, a privacy-friendly analytics service. Crash reports are sent to Sentry. Nothing is sent over the network for either service unless you opt in, and failures in either can never break the app.

Every Aptabase event payload is filtered against a closed allowlist before it’s sent. That means even if something unexpected tried to piggyback extra data onto an event, it would be dropped before it touched the network — the only values that can ever leave your machine are the closed-enum ones documented in the tables above. Sentry reports go through a separate scrubbing step that strips user data, absolute file paths, and unallowed metadata before transmission.

Turning it off

Settings → Privacy → flip Share anonymous usage data off. Telemetry stops immediately — no restart, no fuss. The setting defaults to off, so you’ll only ever be sending data if you explicitly said yes.

Keeping this page honest

If you ever spot a discrepancy between what’s listed here and what Dotvault actually sends, please let me know — it’s a compliance issue, not a cosmetic one.