TL;DR: Datadog bills usually climb because telemetry volume grows across logs, metrics, spans, and hosts faster than anyone governs the inputs, according to Sawmills, and the article maps each meter to the upstream pipeline control that can curb it. Cost control shifts from vendor pricing to telemetry governance, where sampling, filtering, tag hygiene, and retention policy determine the bill.
At a glance
What this is: This analysis argues that Datadog cost is driven by telemetry growth and pipeline decisions, not by the rate card itself.
Why it matters: For observability and identity-adjacent security teams, the lesson is that cost control depends on governing what data is emitted, tagged, retained, and made searchable before it reaches the platform.
Context
Datadog cost becomes difficult to govern when telemetry volume grows faster than the controls that shape it. Logs, metrics, spans, and hosts each create separate billing pressure, and the bill is usually a consequence of upstream instrumentation choices rather than a vendor pricing change.
This matters for security and platform teams because observability pipelines now behave like governed data flows. Where those flows include service identities, workload tags, or automation-generated telemetry, poor control over collection and retention can create both cost risk and operational blind spots.
Key questions
Q: How should teams reduce observability costs without losing useful telemetry?
A: Start at the pipeline, not the backend. Filter obvious noise, remove high-cardinality fields, and tail-sample traces so routine traffic is reduced after full context is available. That preserves error and latency signal while cutting ingest, storage, and query costs before they become locked into the observability bill.
Q: Why do high-cardinality tags create such large cost spikes in observability platforms?
A: Because each unique tag combination becomes a separate billable time series. A single metric can explode when teams add dimensions such as user ID, endpoint, or pod name, especially in containerised systems where labels churn constantly. The cost grows multiplicatively, so the right fix is to govern tags before they are exported.
Q: What breaks when log retention and indexing are not governed separately?
A: Teams end up paying to ingest data they never search, or paying premium rates to keep low-value logs searchable for too long. The failure is assuming every log deserves the same treatment. In practice, searchable retention should be reserved for audit-grade or incident-critical data, while routine telemetry should be kept cheaper and shorter.
Q: Should observability teams prioritise pipeline controls or vendor negotiations first?
A: Pipeline controls first. Negotiating price can help at the margin, but it does not stop telemetry growth from multiplying the bill in logs, metrics, spans, and hosts. The most durable savings come from reducing what is emitted, indexed, sampled, or retained before the platform counts it.
Technical breakdown
Log ingest and indexing create two separate cost surfaces
Datadog logs are billed through two different mechanisms: ingest and indexing. Ingest charges apply to every gigabyte that arrives, while indexing charges apply only to events kept searchable, often with retention tiers layered on top. That means a team can pay for verbose logs it never queries, or for indexed logs that become expensive simply because the retention window is too long. The key technical point is that storage intent and search intent are different control decisions, and mixing them creates hidden cost growth.
Practical implication: classify log streams before they enter Datadog and route only the searchable subset into indexed retention.
Custom metric cardinality turns tag growth into bill growth
Custom metrics are not priced by metric name alone. They are priced by each unique combination of a metric name and its tag values, which means cardinality drives the bill. A low-volume metric can become expensive when tags such as user ID, endpoint, pod name, or status code multiply the number of series. In pipeline terms, the problem is uncontrolled label expansion. Allowlisting tags at collection time is more effective than trying to clean up after ingestion, because the platform never counts what it never receives.
Practical implication: enforce an approved tag list in the telemetry pipeline and strip high-cardinality labels before export.
APM span volume grows with request fan-out, not just traffic
APM cost scales with span volume, and spans grow as requests fan out across service calls, database lookups, cache reads, and queue operations. A single user action can generate dozens of spans in a distributed system. Head-based sampling makes the keep-or-drop choice too early, which risks losing the traces that matter most. Tail-based sampling is technically better because it evaluates the completed trace and can retain errors and latency outliers while discarding routine traffic. The control issue is not visibility itself, but deciding which completed traces deserve full fidelity.
Practical implication: place tail-sampling logic upstream of billing so errors and outliers are preserved without indexing every trace.
NHI Mgmt Group analysis
Telemetry governance, not pricing optimisation, is the real control problem. The article is strongest when it treats Datadog cost as an output of upstream engineering behaviour. That framing aligns with how modern observability estates actually fail, because instrumentation, tagging, sampling, and retention decisions are made in many places and then inherited by the platform. The practitioner conclusion is that finance can only stabilise the bill if platform teams govern the telemetry path continuously.
High-cardinality telemetry is a form of uncontrolled data expansion. The article shows how one tag can multiply a metric into thousands of billable series, which is a governance problem as much as a cost problem. In identity-heavy environments, the same pattern appears when service, workload, or user-adjacent labels are allowed to sprawl without policy. The practitioner conclusion is that tag governance must be treated as a control surface, not a documentation exercise.
Retention policy is the hidden multiplier that turns small mistakes into recurring spend. Long retention windows on logs or spans do not just preserve more history, they amplify every upstream decision that increases volume. This is where data security and observability economics intersect, because what remains searchable also becomes what remains expensive to store and govern. The practitioner conclusion is to classify telemetry by value before it is routed into expensive retention tiers.
Continuous enforcement is the missing operating model. The article correctly notes that one-time cleanup decays as soon as teams ship new services, new tags, or new debug behaviour. That is the same governance failure pattern seen in other control programmes: static policy exists, but there is no operational mechanism to keep it current. The practitioner conclusion is to move from periodic cleanup to standing pipeline governance with policy enforcement at collection time.
Named concept: telemetry pipeline governance. This article usefully names the real discipline behind cost control, even if not in those exact words. The issue is managing telemetry before it becomes billable, searchable, or retained, rather than reacting after usage has already been counted. The practitioner conclusion is that observability spend should be governed like any other production data flow.
What this signals
Telemetry cost control is now a standing governance discipline. Once services, tags, and traces are emitted at scale, the billing outcome has already been shaped. The practical shift for teams is to govern collection rules continuously, not to rely on periodic cleanup after the bill arrives.
Telemetry pipeline governance: the discipline of controlling what telemetry is emitted, how it is labelled, and where it is retained before a platform bills for it. In observability programmes, that means treating sampling, tag policy, and retention as live controls rather than static configuration.
The teams that will stabilise observability spend are the ones that push policy upstream into collection and routing. That is where cost, signal quality, and operational visibility are decided together.
For practitioners
- Implement upstream log filtering Drop health checks, readiness noise, and non-actionable debug chatter in the collector before logs reach ingest or indexing meters.
- Enforce tag allowlists for metrics Strip user-specific or pod-specific dimensions from custom metrics unless the team has explicitly approved the cardinality increase.
- Move to tail-based sampling Preserve error traces and latency outliers at full fidelity while sampling routine traffic after the trace completes.
- Split retention by data value Keep audit-grade telemetry on longer searchable retention and route routine logs and successful spans to shorter, cheaper windows.
- Operate telemetry policy continuously Treat sampling, tagging, and retention as standing controls that are updated as services, deployments, and incident patterns change.
Key takeaways
- Datadog cost escalates when telemetry volume grows unchecked across logs, metrics, spans, and hosts, not simply because the rate card changes.
- The strongest control point is upstream of the platform, where collection, tagging, sampling, and retention decisions determine what becomes billable.
- Treat observability spend as a governed pipeline problem and make telemetry policy a standing operating control, not a quarterly cleanup exercise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Telemetry labels and host sprawl are governance problems similar to unmanaged account growth. |
| Recommendation — Apply CIS-5 discipline to inventory and constrain telemetry sources before they expand billable volume. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-transit is protected | Telemetry pipelines move sensitive and billable data across collection and routing stages. |
| PR.PS-01 — Configuration management | Sampling, filtering, and retention depend on controlled configuration across the pipeline. | |
| Recommendation — Protect telemetry flows in transit and limit what data is forwarded into costly downstream services. Standardise telemetry configurations so collection rules do not drift across services and deployments. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The article focuses on which telemetry is kept, indexed, and analysed for operational value. |
| Recommendation — Use AU-6 to ensure only telemetry with defined review value is retained and surfaced for analysis. | ||
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | Excess telemetry collection and forwarding mirror adversarial collection and data movement patterns. |
| Recommendation — Map telemetry over-collection to ATT&CK collection and exfiltration behaviours when hunting for data overrun. | ||
Key terms
- Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
- Cardinality: The number of unique attribute combinations in telemetry data. High cardinality increases the number of metric series and can inflate cost, overwhelm backends, and make analysis noisy unless attributes are normalised or removed before export.
- Tail-Based Sampling: A trace sampling method that decides whether to keep a trace after the request completes. It preserves error and latency outliers more reliably than early sampling, which makes it useful when teams need value-based trace retention instead of blind volume reduction.
- Retention tier: A retention tier is lower-cost storage used to preserve data for compliance, audit, and later forensic review. It keeps information available without forcing it into the expensive, analyst-facing part of the pipeline.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and governance.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org