Kubernetes in Datadog: What It Costs and How Teams Replace It

TL;DR

• SigNoz: OpenTelemetry-native, priced on data volume rather than node or container count, with a Datadog dashboard migrator and Datadog Receiver support for staged migrations.
• Datadog: Per-host APM, per-container, and custom-metrics charges compound with cluster size; newer OTLP and DDOT paths exist but the per-host billing model still applies.

Datadog Kubernetes monitoring is the bundle of components Datadog ships to pull metrics, logs, traces, and events out of a Kubernetes cluster and into the Datadog backend. It usually consists of three moving parts - the Datadog Agent running as a DaemonSet on every node, the Datadog Cluster Agent running as a centrally managed Deployment that talks to the Kubernetes API server, and the Datadog Operator (or the older Helm chart) that manages those deployments through a Kubernetes-native interface.

Once installed, the Agent auto-discovers workloads through pod annotations, scrapes kubelet and kube-state-metrics, tails container stdout for logs, and forwards everything to Datadog (with OTLP ingest available as a more recent option). The setup is straightforward and the Kubernetes dashboards in Datadog look good in a demo, but the friction shows up at month-end when Datadog APM is billed at $31 per APM host per month with Pro or Enterprise Infrastructure Monitoring (or $36 standalone), Infrastructure Monitoring starts at $15 per infra host per month with additional usage-based charges for containers, logs, and custom metrics, and Datadog's auto-tagging on Kubernetes can attach pod_name, container_id, kube_namespace and similar tags depending on the Agent's cardinality settings, which drives custom metrics counts to numbers that turn into surprise invoice lines.

Most teams running Datadog on Kubernetes report that the K8s monitoring side of the bill grows faster than the cluster itself.
This article walks through how Datadog actually monitors Kubernetes, where the costs and operational pain points compound, and how teams replace the Datadog stack with OpenTelemetry and SigNoz.

What Datadog Drops Into Your Cluster

The classic Datadog install on Kubernetes is four moving parts that ship together. Each one does a different job, and each one is a Datadog component you'll have to swap out if you ever migrate off the Agent path.

• Datadog Agent: Runs as a DaemonSet, putting one Agent pod on every node to scrape kubelet, tail container stdout, forward APM traces from dd-trace-instrumented apps, and collect node-local events. It sends data to Datadog over its native protocol, with OTLP ingest available as an alternative.
• Datadog Cluster Agent: Runs as a centrally managed Deployment, watches the Kubernetes API, runs cluster-level integrations like kube-state-metrics, and exposes the External Metrics API for HPA-driven autoscaling.
• Datadog Operator (or Helm chart): Deploys and reconciles both Agents via a DatadogAgent Custom Resource, with the older datadog/datadog Helm chart as the alternative path on legacy installs.
• Pod annotations: Workload discovery uses ad.datadoghq.com/* annotations as one Autodiscovery method. In workload-managed pods, changes to pod-template annotations apply through a normal rollout rather than hot-updating existing pods.

The Operator, Cluster Agent, and annotation schema are Datadog-specific surfaces, so moving off the classic Datadog Agent path is an operational change across the cluster, not just a code one.

Why the Datadog Kubernetes Bill Compounds

Datadog has several Kubernetes pricing problems that multiply rather than overlap, because every line item on the invoice tracks something Kubernetes naturally produces, like - host count grows as the cluster autoscales, container count grows as more pods spin up, custom metrics cardinality grows with every pod restart, and log volume grows with every sidecar or init container the team adds.
The bill ends up being the product of all four and not the sum.

Per-host pricing scales with node count, not load

Datadog APM and Infrastructure are both priced per host. On Kubernetes, "host" means "node," so a cluster that auto-scales from 20 nodes to 200 during peak load is also auto-scaling your Datadog bill.

The pricing model rewards you for keeping workloads tightly packed on fewer larger nodes and penalises clusters that scale horizontally, which is the opposite of how most Kubernetes-native architectures are built.

Per-container pricing on top

Datadog's container monitoring tier adds a separate per-container fee on top of the node price. The bill ends up structured as host count × per-host APM + container count × per-container + log volume + custom metrics, all of which scale independently with cluster growth.

Custom metrics cardinality from Kubernetes' default tag set

Datadog can automatically attach pod_name, container_id, kube_namespace, kube_deployment, kube_replica_set, and similar tags to Kubernetes metrics, with the exact tag set depending on the Agent's cardinality configuration. Pod names rotate every deploy, container IDs rotate every restart, and replica set names rotate every rolling update.

Rotating high-cardinality tags increases custom-metric usage because billing maps off unique metric-name and tag-value combinations. A team that emits one cleanly-named application metric can end up paying for tens of thousands of unique series once high-cardinality Kubernetes tags are attached.

Log indexing cost on top of ingestion

Datadog Logs charges $0.10/GB for ingestion and an additional $1.06–$2.50 per million events for indexing, with retention adding further multipliers. Kubernetes log volume tends to be high because every sidecar, init container, and ambient platform component emits its own stream, so the indexing line on the invoice is usually larger than teams estimate going in.

DaemonSet resource overhead

The Agent runs on every node, and the Cluster Agent runs centrally. On a busy cluster, the Agent's CPU and memory footprint becomes visible in the resource budget, which means the cluster is also paying its cloud provider for the compute that runs the monitoring stack itself.

DaemonSet, Sidecar, or Gateway: The Topology Flexibility OpenTelemetry Gives You

The classic Datadog Agent path on Kubernetes runs as a DaemonSet, one pod per node. Datadog's newer DDOT Collector also supports OpenTelemetry-style pipelines and a gateway deployment is available in Preview, but the default Kubernetes infrastructure-monitoring path is still the node-level DaemonSet. If your cluster runs hundreds of small nodes on that path, you get hundreds of Agent pods consuming CPU and memory on every node whether you need them or not.

OpenTelemetry gives you three patterns and lets you pick per workload:

• DaemonSet: Same shape as the Datadog Agent. One Collector per node, scrapes local kubelet and cAdvisor, tails local container logs. Best when most data is node-local.
• Sidecar: A Collector container injected next to your application pod. Stronger isolation and zero noisy-neighbour risk between workloads, at the cost of a Collector container per pod. Rarely needed, but available.
• Gateway: A centralised Collector deployment that the cluster ships data to. Zero per-pod overhead and horizontally scalable, so your monitoring stack scales independently of cluster size. Best for high-traffic clusters or any team optimising the resource footprint of their observability layer.

Datadog vs OpenTelemetry for Kubernetes

The contrast comes down to one design choice - Datadog's Kubernetes stack is built around its own Agent, Cluster Agent, and Operator, while OpenTelemetry is an open standard that any backend can implement and any team can run without committing to a single vendor.

Most pieces of the Datadog Kubernetes stack have a direct OpenTelemetry equivalent that does the same job without binding the cluster to one vendor.

Why SigNoz Fits Kubernetes Better Than Datadog

The Datadog-to-OpenTelemetry swap is the easy part. The harder question is which OTel backend the data actually goes to once the Datadog Agent is out, and there are several to choose from. The practical reasons teams coming off Datadog on Kubernetes end up on SigNoz come down to the following.

Your Datadog Muscle Memory Carries Over

SigNoz's UI is built around the same primitives a Datadog user already knows. The Kubernetes resource views, pod and node-level dashboards, trace waterfalls, and log explorer map closely to their Datadog equivalents, so the team's existing Datadog muscle memory carries over instead of being thrown away. That tends to keep migration risk lower than picking a tool with a completely different mental model.

Logs, Metrics, and Traces in One Platform

SigNoz keeps logs, metrics, and traces in a single platform with a unified query experience (a visual builder, raw SQL, and Prometheus-style expressions from one UI) and a single bill. Pivoting from a trace to its logs to the host or pod metrics behind it happens inside one product, so an incident never turns into a tab-switching exercise across separate tools and the team isn't juggling four disconnected query UIs to answer one question.

No Per-Host or Per-Container Bill

Datadog APM is billed per host (starting at $31 per APM host per month with Pro or Enterprise Infrastructure Monitoring, or $36 standalone), per-container charges sit on top, and both scale with cluster size.

SigNoz prices ingested data at $0.30/GB for logs and traces and $0.10 per million metric samples, with no per-host, per-container, or per-user charges. Adding nodes, pods, or engineers doesn't change the line item, and the bill is bounded by data volume alone.

High-Cardinality Kubernetes Tags Without the Bill Penalty

Most teams moving off Datadog on Kubernetes have hit cardinality issues somewhere, often because Datadog's auto-tagging can attach pod_name, container_id, and kube_deployment depending on cardinality settings, and each rotation creates new billable time series.

SigNoz handles high-cardinality data natively and doesn't bill per time series, so the same Kubernetes tags that drove your Datadog overage cost the same as any other tag on SigNoz. You can keep pod_name, container_id, and any custom tag you actually need for debugging without rewriting your tagging strategy.

OpenTelemetry-Native, So There's No Second Lock-In

A few backends accept OTLP traffic but push their own agents or SDKs back onto you for full feature parity. Picking those means trading one lock-in for another, which is exactly what you were trying to avoid when leaving the Datadog Agent.

SigNoz is built on OpenTelemetry from the ground up, so the instrumentation work you do for SigNoz keeps working with any other OTLP-compatible backend if you ever switch again.

Migration Tooling Built for This Move

Most OTel destinations leave the migration entirely up to you. SigNoz ships a Datadog dashboard JSON migrator that converts your existing Datadog dashboards (including Kubernetes dashboards) into SigNoz dashboards in one step, supports the open-source OpenTelemetry Datadog Receiver so you can forward Datadog Agent traffic to SigNoz while you swap collectors at your own pace, and publishes migration documentation specifically for the Datadog Agent and Operator. The combined effect is that staged migrations stay in production-readable shape from day one rather than going through a long cutover.

FAQs

How does Datadog monitor Kubernetes?

Datadog Agent (DaemonSet) + Cluster Agent (Deployment) + Operator (or Helm chart). SigNoz Cloud collapses all three into one OpenTelemetry Collector.

Is the Datadog Agent open source?

Source is on GitHub but tied to Datadog's backend. SigNoz Cloud is OpenTelemetry-native end to end.

Datadog Operator or Helm chart, which one should I use?

Both still work. Starting fresh, the OpenTelemetry Operator pointed at SigNoz Cloud is the OTel-native equivalent.

Does Datadog charge per Kubernetes node?

Yes — Infrastructure Monitoring from $15/host, APM from $31 (Pro/Enterprise) or $36 standalone, plus per-container and custom-metrics charges. SigNoz Cloud prices on data volume ($0.30/GB), so node count doesn't change the bill.

Why does my Datadog bill grow when my cluster auto-scales?

Per-host pricing scales with node count. SigNoz Cloud's volume-based pricing doesn't.

Can I move from the Datadog Agent to the OpenTelemetry Collector on Kubernetes?

Yes. Install the OpenTelemetry Operator, deploy a Collector DaemonSet plus gateway, point apps at OTLP, send everything to SigNoz Cloud. Steps in the migration guide linked at the top.

Does SigNoz work with the Datadog Operator?

No. Use the OpenTelemetry Operator with SigNoz Cloud — same Kubernetes-native experience, no per-host bill.

Can I keep dd-trace on Kubernetes and use SigNoz?

Yes. The OpenTelemetry Collector's Datadog Receiver forwards existing Datadog Agent and dd-trace traffic to SigNoz Cloud over OTLP, so you can stage the migration without swapping SDKs.