Zomg uses pseudonymous CLI telemetry to understand which commands and operating environments are used by the open-source project. Telemetry is designed to be transparent, easy to disable, and limited to product usage signals. No telemetry is sent before the first-run notice is shown. The command that shows the notice is skipped.

​
Controls

zomg telemetry status
zomg telemetry off
zomg telemetry on
zomg telemetry log
zomg telemetry explain
Environment overrides take precedence over local config: 
ZOMG_TELEMETRY=off
ZOMG_TELEMETRY=log
DO_NOT_TRACK=1
zomg telemetry log stores log mode. Future telemetry payloads are printed to stderr instead of being sent.

​
Payload

Zomg sends cli.command events with a random local installation_id, command and subcommand names, flag names, OS, architecture, CI detection, duration bucket, result, and coarse error class. Zomg CLI telemetry does not collect command argument values, shell commands passed to zomg exec or zomg console, file paths, box names, project names, hostnames, usernames, emails, environment variable values, tokens, secrets, or raw error messages. Use zomg telemetry log to inspect the exact payloads that would be sent.

​
Endpoint

By default, CLI telemetry is posted to: 
https://telemetry.zomg.ai/v1/events
The endpoint can be overridden with ZOMG_TELEMETRY_ENDPOINT. Invalid or unreachable endpoints fail silently and do not block command execution. The hosted receiver lives at loopwork/forkr-telemetry. It validates the exact event schema, rejects unknown fields, does not read or forward request headers, and forwards valid events to PostHog with $process_person_profile: false. Production forwarding requires a dedicated PostHog project token configured on the receiver as POSTHOG_PROJECT_API_KEY.

​
Deployment Metrics

Zomg deployment utilization telemetry is separate from CLI telemetry. Detailed deployment metrics such as node shape, active boxes, storage utilization, user counts, and service counts should be exported only through an explicit setup opt-in flow.