As observability data grows, many SaaS vendors are moving from flat subscriptions to usage-based billing for telemetry: charge for what customers ingest, retain, or query. Doing this well requires technical controls (sampling, cardinality limits, tiered storage), a reliable metering pipeline, and a clear customer UX. This guide walks you through a concrete, production-ready approach to design and operate usage-based observability billing for a SaaS product in 2026 using OpenTelemetry and modern ingestion controls like eBPF.

Why usage-based observability billing matters in 2026

Telemetry volumes continue to multiply—high-cardinality metrics, verbose traces from distributed apps, and long-tail logs. At the same time, OpenTelemetry has become the de-facto instrumentation standard and eBPF is widely available for low-overhead data capture. That combination makes usage-based billing both feasible and necessary:

  • It aligns customer cost with value and reduces cross-subsidy between light and heavy users.
  • It creates revenue opportunities for add-ons (longer retention, raw logs exports, richer trace retention).
  • It forces engineering controls that reduce platform costs (cardinality hygiene, aggregation).

High-level architecture

Design a pipeline that separates metering from long-term storage and supports enforcement without dropping customer signals silently. Core elements:

  • Client-side/OpenTelemetry instrumentation (SDKs, auto-instrumentation).
  • Edge controls: native SDK attribute filtering, SDK-level sampling, and eBPF layer for host-side capture when relevant.
  • OpenTelemetry Collector cluster(s) for enrichment, attribution, aggregation and metering.
  • Stream layer (Kafka, Pulsar, cloud Pub/Sub) for durable event transport.
  • Short-term hot store for real-time queries and billing reconciliation (ClickHouse, Timescale, Mimir, Cortex).
  • Cold/archival storage for long-term retention (object storage + index summarization).
  • Billing pipeline that consumes metering records, aggregates usage by billing period, applies plans and produces invoices.

Step 1 — Pick the billing unit(s)

There’s no single correct billing unit. Most successful SaaS observability products combine multiple units to balance predictability and fairness. Common units:

  • Ingested bytes: simple to measure but penalizes human-readable logs and large spans.
  • Unique time-series (metric series) per minute: captures cardinality costs; preferred for metrics-heavy platforms.
  • Sampled traces or spans: count of traces ingested or stored after sampling.
  • Log lines or indexed log events: when you index logs for search, indexable events matter.
  • Query or egress units: charge for export, long-tail queries or raw data egress.

Recommendation: choose a primary metric (e.g., metric series-minute for metrics, sampled trace count for traces, indexed log events for logs) and expose secondary charges (retention days, long-term exports, archive restores).

Step 2 — Instrumentation and cardinality hygiene

Prevent runaway cardinality at the source. OpenTelemetry provides attribute-level control but you must enforce conventions.

  1. Define allowed attributes and naming conventions: Create org-level attribute whitelists and standardized metric/label naming. Publish a spec and SDK wrappers so app teams get consistent defaults.
  2. Normalize identifiers: Hash or truncate high-cardinality values (user IDs, session tokens) before they reach the collector unless required for debugging.
  3. Use derived metrics: Turn high-cardinality logs into low-cardinality derived metrics via counters and histograms at the client or collector.
  4. Adopt eBPF selectively: For host-level telemetry where SDK changes aren’t possible, eBPF-based collectors (2024–2026 adoption broadened) can capture signals and apply filtering close to the kernel, minimizing unnecessary ingestion.

Step 3 — Sampling and aggregation strategies

Sampling is central to controlling cost without losing signal. Use a mix:

  • Head sampling: Drop a fixed percentage early for noisy sources. Good for very high-volume sources.
  • Tail sampling: Keep traces that are rare or error-prone—e.g., sample all traces with error flags, sample a small percentage of successful traces.
  • Adaptive sampling: Real-time sampling rate adjustments by customer or source when budgets/quotas approach limits.
  • Aggregation/rollups: Convert raw spans or log lines into aggregated counters/histograms for long-term storage.

Implement sampling in the SDK for immediate reduction and in the collector for more context-aware decisions (collector can access resource attributes and enforce per-tenant quotas).

Step 4 — Metering pipeline: reliable, auditable usage records

Metering must be accurate and explainable to customers. Design a metering path separate from the primary observability streams:

  1. Emit compact usage events at the collector for every billing-relevant action: metric-series-minute increments, sampled trace ingestion, indexed log event.
  2. Send usage events to a durable stream (Kafka or cloud Pub/Sub) and write them into an immutable ledger (daily partitions) for reconciliation.
  3. Apply plan logic in a batch or near-real-time aggregator to produce per-customer usage statements and thresholds.
  4. Keep raw metering records for N months (regulatory or dispute resolution) and expose them to customers via an audit endpoint.

Auditability is key: customers will dispute charges. Store both pre-aggregation and post-aggregation records and tie them to tenant IDs and request IDs where possible.

Step 5 — Quotas, enforcement and graceful degradation

Enforcement should be predictable and non-surprising:

  • Soft quotas: Alert customers at 70% and 90% consumption and offer automated plan upgrades or purchases.
  • Hard quotas: Enforce when customers exceed paid limits: block ingestion, apply aggressive sampling, or move data to limited retention tier.
  • Graceful degradation: Don’t abruptly drop all traces; rather apply rate-limiting and increase sampling rates with clear headers or signals to the SDK so apps can adapt.

Expose quota status via API and standard telemetry so customers can instrument their own cost alerts.

Step 6 — Tiered storage and retention

To balance cost and product value, implement storage tiers:

  • Hot tier: Recent data (hours to days) stored in fast index for queries and dashboards.
  • Warm tier: Aggregated and compressed data for medium-term retention (weeks).
  • Cold/Archive: Object storage with compact indexes for long-term compliance or occasional restores.

Charge customers for retention beyond the included baseline. Provide an elastic model: cheap archival, premium instant retrieval.

Step 7 — Customer UX, transparency and dispute handling

Billing transparency reduces churn. Provide:

  • Real-time usage dashboards with breakdown by signal (metrics, traces, logs), by service, and by tag.
  • Forecasts and alerts that estimate month-end usage at current rate.
  • Line-item invoices that map to metering records; allow CSV export and API access for reconciliation.
  • Self-serve quota edits and plan upgrades; for enterprise customers, offer negotiated committed-use discounts.

Document measurement methodology (what counts, how sampling affects counts) and publish an SLA for metering accuracy and dispute resolution timelines.

Step 8 — Billing plumbing and integration

Integrate metering with your financial systems:

  1. Aggregate usage by billing period and apply plan rules (free tier, included units, overage rates).
  2. Generate provisional invoices and allow customers to preview before finalization.
  3. Feed finalized amounts to your billing system (Stripe, Zuora, Chargebee) with sufficient metadata for customer accounting.
  4. Maintain a reconciliation job that compares ledgered metering records to billed amounts monthly and flags anomalies.

Step 9 — Monitoring, KPIs and fraud detection

Track platform and business KPIs to tune pricing and detect misuse:

  • Cost per ingest unit (by signal type), gross margin by plan, and customer-shaped usage curves.
  • Alerts for sudden spikes in per-tenant ingestion indicating runaway code or abuse.
  • Automated throttles for API keys showing anomalous patterns, with human-in-the-loop review for false positives.

Step 10 — Launch strategy and migration

Move slowly and give customers time to adapt:

  1. Start with new customers on usage-based plans while keeping existing customers on legacy plans.
  2. Offer a hybrid model: a base subscription plus usage charges, and a predictable "committed use" option for large customers.
  3. Run a pilot with selected customers and provide a sandbox to estimate their expected bill under the new model.
  4. Communicate clearly: show examples, run webinars, and provide a cost-impact calculator.

Concrete examples and vendor considerations

Operational choices depend on your stack. Examples:

  • If you use OpenTelemetry Collector + Kafka + ClickHouse for hot storage, push metering events from the collector directly to a metering Kafka topic. Aggregate in ClickHouse for fast per-tenant rollups.
  • If you rely on managed providers (Datadog, Honeycomb, Lightstep) for parts of your pipeline, map their pricing primitives to your plan model—e.g., sampler-adjusted trace counts, billed retention tiers—and include that cost in your unit economics.
  • For high-performance host telemetry, eBPF-based capture (via vendors or OSS like Pixie, Tetragon) lets you filter early and reduce ingestion while preserving visibility for critical signals.

Checklist before going live

  • Decided billing units and published them publicly.
  • Implemented SDK/collector-level attribute controls and cardinality hygiene rules.
  • Built a durable metering stream and immutable ledger for audit.
  • Implemented quota APIs, soft warnings and hard enforcement paths.
  • Exposed customer-facing usage dashboards and forecast alerts.
  • Integrated metering with billing and reconciliation processes.
  • Ran a pilot and updated documentation and support flows.

Common pitfalls and how to avoid them

Watch for these frequent mistakes:

  • Opaque measurement: If customers can’t see how usage is measured, they’ll distrust bills. Publish methodologies and raw metering exports.
  • No soft limits: Hard shuts without warning cause outages and churn. Use staged enforcement.
  • Metering coupled to sampling heuristics: If you change sampling aggressively, make sure metering logic compensates so customers aren’t surprised by bill swings.
  • Underestimating cardinality: High-cardinality dimensions can explode costs; instrument and test against representative production workloads.

Final thoughts

Usage-based observability billing is both an engineering project and a product redesign. By using OpenTelemetry as the instrumentation standard, applying cardinality and sampling controls near the source (SDKs and eBPF), separating metering from storage, and providing transparent customer-facing tools, SaaS vendors can convert ballooning telemetry costs into predictable, monetizable units of value. Start with pilot customers, make the measurement auditable, and iterate pricing around real cost signals—not guesswork.