Telemetry cost and volume management

To understand telemetry cost, measure event frequency, payload size, retention, data scanned by queries, exports, and the number of distinct field values. Total bytes alone cannot explain a vendor bill. Check these measurements before cutting collection so you know which data you would lose and which costs you might reduce.

How Telemetry bills query compute

Query hours mean CPU-hours, not the elapsed time shown by a query timer. We measure actual operating-system thread CPU time for query preparation and execution through result materialization, including participating workers on other nodes. One CPU-hour is 3,600 CPU-seconds.

• Eight fully busy CPUs for ten seconds consume 80 CPU-seconds, or about 0.0222 CPU-hours.
• One fully busy CPU for 80 seconds consumes the same amount. Allocating eight CPUs does not itself incur eight times the charge: we measure the CPU actually used.
• Waiting for a scheduling slot, memory admission, or I/O does not consume billable query CPU. Unrelated background maintenance is not charged as query CPU.

Free includes 1 CPU-hour per month, Business includes 10, and Enterprise includes 100. Extra usage on paid plans costs $0.30 per CPU-hour. In the 80 CPU-second example, compute overage is approximately $0.00667 if the included allowance has already been used. Seat and storage charges are separate; see pricing and the cost calculator.

Why CPU time rather than elapsed time?

We think charging for measured compute is fairer than charging for time spent waiting. Under load, a query may take longer without doing more CPU work. Conversely, a parallel query can finish quickly while using many CPUs. CPU accounting makes that work visible rather than charging only for the fastest worker's duration.

For distributed queries, each completed worker fragment's CPU is counted once, plus the coordinator's own CPU. We do not charge the aggregated worker CPU again at the coordinator. Parallel execution is not a promise of a lower bill: coordination and retries can add work, and there is no cap at an estimated single-node cost.

Failures and retries

Billing currently sums recorded successful completions. A failed or cancelled execution does not itself write a successful billable completion record. However, a distributed fragment may complete and be recorded before another fragment or the parent fails. That completed work remains in usage, and a successful retry can add more usage. Do not assume that every failed request or retry is free.

CPU-metered queries have no 300 ms per-query minimum.

The meter excludes subsequent query-log writes and detached cleanup. Query timers and latency charts still report elapsed time; they are not a substitute for billing usage. Compare CPU usage as well as latency when evaluating an optimization. Dashboard refreshes and alert evaluations that run queries also consume query compute.

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.