Telemetry
Browse docs
GuidesUpdated July 28, 2026Reviewed by the Telemetry product team2 min read

Use this doc with your coding agent

Copy a Telemetry prompt and ask Claude Code, Codex, or Cursor to instrument the workflow covered here.

PromptsGet API key
On this page
  1. Measure the event contract first
  2. Review cardinality and usefulness
  3. Change collection safely

Telemetry Cost and Volume Management

Telemetry volume has several different drivers: event frequency, serialized payload size, retention, query scan patterns, exports, and the number of distinct dimension values. No single byte total is a complete vendor bill, but measuring these inputs makes waste and risky collection changes easier to review.

Measure the event contract first

At ingestion, record a compact operational event with the controlled event name, bounded producer source, serialized payload bytes, schema version, acceptance outcome, and environment. Do not duplicate the original payload into the measurement event.

The telemetry volume SQL recipe groups count and payload bytes by event contract. It also calculates average event size and rejection rate. This distinguishes a high-frequency small event from a lower-frequency oversized event and prevents a cost change from silently degrading data quality.

Serialized bytes are not the same as compressed storage, scanned bytes, network egress, or invoice cost. Connect the aggregate with your actual retention and pricing model before forecasting money.

Review cardinality and usefulness

A small event can still create an unusable dashboard if fields such as raw URL, request ID, error message, or user-generated label become grouping dimensions. Follow the high-cardinality fields guide and keep identifiers for targeted drill-down rather than default charts.

For each large contract, document:

  1. The decisions, dashboard, alert, or investigation it supports.
  2. Required fields and fields that can be removed or categorized.
  3. Production sampling rules and the questions sampling would prevent.
  4. Retention and deletion requirements.
  5. The owner who reviews schema and volume changes.

Change collection safely

Start with development noise, accidental duplicates, and fields that have no reader. Test schema changes and rejection behavior before reducing production data. Compare complete daily buckets after the rollout so a traffic change is not mistaken for an instrumentation win.

Use the data quality recipe collection to monitor freshness, duplicates, null fields, and schema adoption while changing volume. The data retention guide covers policy and deletion decisions that should remain separate from query optimization.