Kubernetes observability cost: why K8s breaks your Datadog bill

TL;DR: Kubernetes telemetry is structurally expensive on per-host and GB-based platforms. A 50-node cluster on Datadog runs $10,400-11,400/month at published pricing, and $13,000-18,000 once you add rich labels, longer retention, or extra modules. The same cluster on base14 Scout with signal-based pricing ($250/month platform fee + $0.10/M metrics + $0.25/M logs & traces) costs $1,550-3,350/month. The difference comes from how each model handles cardinality, and Kubernetes generates a lot of it.

Your Kubernetes observability bill scales with your cluster's cardinality, not with your workload. Every pod restart creates new label combinations. Every HPA scaling event creates new time series. Every namespace, annotation, and sidecar container multiplies the dimensions your observability platform tracks.

On platforms that charge per host, per GB, or per custom metric, this is a structural problem. Kubernetes generates high-cardinality telemetry by design, and traditional pricing models charge more when it does.

Teams respond by stripping labels, sampling traces, shortening retention, and aggregating metrics. They reduce costs by reducing the context they will need during the next incident.

That is the Kubernetes observability cost problem. It is less about finding the cheapest vendor than about picking a pricing model that does not force a choice between cost control and debugging capability.

Why Kubernetes breaks per-host pricing​

Traditional infrastructure monitoring was built for a world where hosts were stable, identifiable, and countable. You had 50 servers, you paid for 50 hosts, and the math was straightforward. Kubernetes breaks every assumption in that model.

The cardinality explosion​

A single Kubernetes node doesn't generate telemetry like a single VM. Each node runs multiple pods. Each pod has one or more containers, and each container produces its own metrics, logs, and traces. The metadata attached to that telemetry includes pod names with random hash suffixes, container IDs, namespace labels, deployment labels, and replica set names.

A 50-node cluster running 30 pods per node means 1,500 pods. Each pod carries 10-15 metadata dimensions. Multiply by the metrics each pod emits, and you're looking at hundreds of thousands of unique time series that churn constantly as pods restart and reschedule.

On Datadog, every unique combination of metric name and tag set counts as a custom metric beyond a small included allotment. At $1 per 100 custom metrics, a K8s cluster that generates 50,000 custom metrics from kube-state-metrics and cAdvisor alone adds $500/month before you've instrumented a single application.

Ephemeral pods and billing floors​

Kubernetes pods are ephemeral by design. They crash, restart, get rescheduled to different nodes, and scale up and down with load. But observability billing often isn't ephemeral. Datadog uses high-water mark billing for per-host pricing: your monthly cost is based on the peak number of hosts observed during the billing period, not the average.

An autoscaling event that spins up 20 extra nodes for a two-hour traffic spike counts toward the whole month's bill. For teams running Kubernetes with aggressive autoscaling, the gap between average utilization and peak billing can be significant.

Log volume from orchestration noise​

Kubernetes control plane components are verbose. The API server, scheduler, controller-manager, and etcd all produce logs. Add container stdout/stderr, kubelet logs, and sidecar containers (Istio Envoy proxies are prolific log generators), and a 50-node cluster can produce well over a hundred gigabytes of logs per day.

Most of this volume is orchestration noise. Teams rarely query it, but they always pay for it on GB-based platforms. The alternative is dropping logs at the collector level. That saves money, but it also means losing the data that explains why the cluster made the decisions it did during an incident.

The five signals to collect from Kubernetes​

Most Kubernetes monitoring pricing discussions focus on three signals: metrics, logs, traces. In Kubernetes, two additional signal types are equally critical for understanding what happened and why.

Metrics: pod, node, and cluster health​

Kubernetes metrics come from multiple sources. The kubelet reports pod-level resource usage. kube-state-metrics exposes cluster state like deployment status and pod phases. cAdvisor provides container-level data, and node exporters cover hardware metrics.

The signals that matter most: CPU and memory per pod, pod restart counts, RED metrics (request rate, error rate, duration) per service, and HPA scaling events. Each generates high-cardinality time series because label dimensions change constantly.

Logs: container, kubelet, and control plane​

Container logs stream from stdout/stderr. Kubelet logs capture node-level events. Control plane logs from the API server, scheduler, and etcd tell you why the cluster made scheduling and scaling decisions.

The challenge is ephemeral pods. A DaemonSet log collector must ship logs off-node before the pod dies, or those final crash lines are gone permanently.

Distributed traces: request flow across services​

A single user request in a Kubernetes microservices architecture might traverse 5-15 services across dozens of pods. Without distributed tracing, debugging is guesswork. You see the symptom in one service and the cause lives in another, with no way to connect them.

The trace that reveals root cause is often the one that gets sampled away on platforms where trace retention is expensive.

Kubernetes events: scheduling and lifecycle records​

Events are Kubernetes' native notification system: pod scheduling, image pulls, container starts and kills, probe failures, HPA decisions. These are often ignored in observability setups, but they answer the question that infrastructure metrics cannot: "What changed?" When a deployment rollout coincides with a latency spike, the event stream connects the two. For more on observing these silent failures, see Kubernetes scheduling: observing silent failures.

Resource state: deployments, ConfigMaps, services​

Beyond events, the current state of Kubernetes resources tells a story. A ConfigMap change that propagated to 50 pods. A service endpoint update that rerouted traffic. Correlating resource state changes with performance anomalies is what separates reactive monitoring from useful Kubernetes observability.

What a 50-node cluster costs​

Let's put real numbers on this. The scenario: a 50-node Kubernetes cluster running microservices, averaging 30 pods per node, with standard observability requirements (infrastructure metrics, APM, logs, traces).

Datadog: per-host + per-metric + per-GB​

Datadog's published pricing breaks down across multiple billing dimensions. For a 50-node K8s cluster:

Pricing as of August 2026. Based on publicly listed annual billing rates. Custom metrics count depends on integrations and labels enabled. Verify at datadoghq.com/pricing. Actual costs vary by contract.

These numbers are conservative. Teams that keep rich Kubernetes labels on their custom metrics, retain logs beyond 15 days, or run additional Datadog features (Synthetics, Database Monitoring, CSPM) regularly see bills in the $13,000-18,000/month range for clusters this size. For a deeper breakdown of Datadog's billing mechanics, see our Datadog alternative comparison.

New Relic: per-seat + per-GB​

New Relic's model is structurally different but creates its own K8s cost pressure. The host count doesn't directly drive the bill, but data ingest does:

Assumes 5 Full Platform + 3 Core users and ~9,000 GB/month of total ingest (about 300 GB/day) beyond the free tier. Verify at newrelic.com/pricing.

New Relic's per-seat model means cost scales with team size, not cluster size. Small teams with large clusters may pay less than Datadog. Larger organizations where many engineers need query access see per-seat costs add up quickly. See our New Relic alternative analysis for more detail.

base14 Scout: signal-based pricing​

Scout charges per signal (one metric data point, one log line, or one trace span) regardless of size, cardinality, or metadata attached. Rich Kubernetes labels don't inflate costs.

Doubling every signal volume above brings the total to about $2,850/month. The top of the range, around $3,350, assumes heavier log and trace volume. There are no per-host charges, no custom metric surcharges, and no penalty for keeping every Kubernetes label on every signal.

The difference is not only the number, it is what you keep. On Datadog, teams strip labels and sample traces to control costs. On Scout, full cardinality costs the same as aggregated data.

Side-by-side summary​

All estimates assume published pricing, annual billing, 50-node K8s cluster with moderate microservices workload. Actual costs vary by contract, volume commitments, and feature usage.

What you give up to cut cost​

The Kubernetes observability cost problem is not only the invoice. It is the debugging capability teams give up to keep that invoice manageable.

Label stripping​

When custom metrics cost $1/100 and your K8s cluster generates thousands of unique label combinations, teams strip labels to control cost. Pod names get aggregated away, container IDs are dropped, and custom annotations are never shipped.

This works fine until the incident where you need to isolate a specific pod's behavior, and the label that would have identified it was stripped at collection time to save $200/month.

Trace sampling​

Sampling traces at 10% or 1% makes sense from a cost perspective. From a debugging perspective, it means the P99 latency spike affecting 0.5% of requests is invisible. The trace that would show root cause was never stored.

Teams end up spending engineering hours reconstructing what a complete trace would have shown them instantly.

Short retention​

With 15-day log retention (Datadog's default indexed retention), you can't investigate last month's anomaly. You can't compare this week's deployment against a baseline from three weeks ago.

Memory leaks build over days, pod degradation takes weeks to surface, and configuration drift compounds silently. None of it is visible once the retention window closes.

On Scout, 30-day default retention at full resolution means the data is there when you need it. Extended retention is available at minimal cost for teams that need longer lookback windows.

Running Kubernetes and wondering what your cluster costs to observe? Book a 15-minute demo and we'll model your workload against signal-based pricing.

How to reduce Kubernetes observability cost​

If your Kubernetes monitoring pricing does not match how Kubernetes generates telemetry, a bigger discount from your current vendor only delays the problem. What changes the trajectory is a pricing model built for dynamic, high-cardinality infrastructure.

Audit your current spend​

Before switching anything, understand where your money goes. Most teams are surprised by how much they spend on custom metrics from Kubernetes integrations they never configured intentionally. Check your Datadog custom metrics count, your log indexing volume versus what gets queried, and your trace sampling rate versus what you'd want during an incident.

Evaluate signal-based alternatives​

Signal-based pricing counts one log line, one metric data point, or one trace span as one signal. Size and labels don't matter. This eliminates the cardinality tax that makes Kubernetes expensive to observe. For a framework on evaluating platforms, see our observability platform evaluation guide.

Keep OpenTelemetry as your collection layer​

Whatever backend you choose, instrument with OpenTelemetry. OTel is the second most active CNCF project after Kubernetes itself, and it ensures your instrumentation is portable. If you change backends next year, your code doesn't change. For production collector configuration, see building a production-ready OTel collector.

Treat observability cost as an architecture decision​

Observability spend should scale predictably with your workload, not spike unpredictably with your cluster's cardinality. If your current platform penalizes you for keeping the context you need, that's not a budgeting problem; it's an architecture problem. For a broader analysis of how pricing models affect observability decisions, see our observability cost optimization guide.

Kubernetes generates high-cardinality, multi-signal telemetry across ephemeral infrastructure. That is how container orchestration works. The question is whether your observability pricing model charges you extra for it.

FAQ​

Why is Kubernetes monitoring so expensive on Datadog?​

Kubernetes generates high-cardinality telemetry through unique pod names, container IDs, and label combinations. Datadog charges per host ($15-27/month for infrastructure, $31/month for APM) plus custom metrics at $1 per 100, which compounds quickly in dynamic K8s clusters where pods and labels multiply constantly.

How much does monitoring a 50-node Kubernetes cluster cost on Datadog vs signal-based pricing?​

A 50-node K8s cluster on Datadog with infrastructure monitoring, APM, and logging costs $10,400-11,400/month at published rates, rising to $13,000-18,000 with rich labels, longer retention, or additional modules. The same cluster on base14 Scout with signal-based pricing ($250/month platform fee + $0.10/M metrics + $0.25/M logs and traces) runs $1,550-3,350/month depending on telemetry volume.

What is signal-based pricing for observability?​

Signal-based pricing charges per data point (metric sample, log line, or trace span) regardless of size or cardinality. This means rich Kubernetes labels, full stack traces, and custom annotations don't inflate costs, unlike GB-based or per-host models where metadata size directly affects your bill.

How does Kubernetes cardinality affect observability costs?​

Every Kubernetes pod gets a unique name with a random hash. Multiply by namespaces, deployments, labels, and annotations, and a 50-node cluster can generate hundreds of thousands of unique time series. On platforms that charge per custom metric or per GB, this cardinality explosion drives costs up without adding workload.

Related reading​

• Why two monitoring stacks cost more than one platform
• How to evaluate an observability platform
• Observability cost optimization: why the pricing model matters
• Kubernetes scheduling: observing silent failures
• The problem with observability theatre