Product Telemetry

Product telemetry is the bounded information a LyftData installation sends to a telemetry receiver for product support, fleet health, first-seen detection, and usage summaries. It has a separate privacy and security posture from local workload observability.

Applies to

Product telemetry is a beta capability for Community and Enterprise single-node and distributed-worker deployments. Verify the payload, receiver, and controls for your selected release.

Caution

Product telemetry is not OpenTelemetry export. It is also not the local logs, metrics, traces, runtime artifacts, or job payloads you use to operate workloads.

What the product reports

The current product telemetry contract contains:

• installation and machine identifiers;
• build version, platform, architecture, and collection timestamps;
• bounded system summaries such as CPU, memory, disk, uptime, and connection counts;
• usage summaries including total and average-per-second event and byte counts, aggregate error rate, and active job and worker counts;
• job summaries including jobs created, completed, and failed today, average job duration, and counts by job type; and
• worker summaries such as total, active, utilization, and average load.

Installation and machine identifiers are not customer payloads, but they can identify an installation. Treat them as sensitive operational metadata.

Product telemetry should not contain raw workflow input or output, raw logs, raw traces, SQL rows, runtime artifact bytes, access tokens, or secrets. If your deployed receiver or custom relay adds fields, review that separate contract before enabling it.

Where data goes

A product installation sends an authenticated request to its configured telemetry receiver. Release profiles can resolve different production, beta, or development endpoints. Inspect the resolved destination for the exact installed release; do not infer it from a hostname copied from another build.

The receiver requires a bearer token. Production deployments must use an explicit token and protected TLS. Development fallback tokens and self-signed or disabled TLS are local-development postures, not production defaults.

Receiver storage can be SQLite for development or an explicitly reviewed small deployment. Production receiver posture depends on the deployed database, transport security, least-privilege roles, archive protection, backup, and restore controls. A product build supporting the receiver does not certify that a particular receiver deployment meets those controls.

Enable or disable sending

Product telemetry is enabled by default in the current server configuration and collected on a periodic interval. To disable product telemetry, start the server with:

lyftdata run server --disable-telemetry

The existing environment equivalent is:

export LYFTDATA_DISABLE_TELEMETRY=true
lyftdata run server

Restart the server after changing startup configuration and record the decision in your deployment runbook. Disabling product telemetry does not disable local logs, metrics, traces, health checks, or OpenTelemetry jobs.

When product telemetry is enabled for a non-local or production-like receiver, the server rejects the development fallback token. This fail-closed check prevents accidental production sending with a shared development credential.

Retention, access, and deletion

The standard telemetry receiver has configurable retention with a 30-day default. A background job removes expired database rows and old archive objects. The receiver operator must align:

• primary database retention;
• spillover or archive retention;
• backup retention and encryption;
• access to restore media; and
• deletion requests and customer commitments.

Deleting receiver rows does not automatically delete backups, replicated stores, Portal summaries, or data sent through a custom relay. Track each system in the data inventory and verify deletion at its own boundary.

Access to the receiver and stored telemetry should be restricted to named support, operations, product, or commercial roles with a documented need. Tokens belong in the owning secret store and must not be logged or committed.

Failure behavior and monitoring

Product telemetry is not on the workload data path. A receiver failure should not be interpreted as a job failure, and a healthy receiver does not prove workers or jobs are healthy.

For receiver readiness, inspect the receiver /health JSON fields rather than HTTP status alone. The response can remain HTTP 200 for compatibility while status, database_ok, or writer_ok reports degradation.

Monitor receiver authentication failures, rejected payloads, writer backlog, archive spillover, retention activity, and storage growth. Keep receiver service logs free of payload bodies and tokens.

Security and privacy review

Before enabling product telemetry in a governed environment:

1. Record the exact product version and resolved receiver destination.
2. Review the payload classes above against your data inventory.
3. Confirm bearer-token custody and rotation.
4. Confirm TLS and database transport posture.
5. Set and test retention, backup, restore access, and deletion.
6. Confirm who can query the receiver and for what purpose.
7. Verify that raw workload content is not included.
8. Record how to disable sending and how to verify the change.

For local workload signals, return to Telemetry. For trace sampling and export, see Distributed Traces.