Looking for a Datadog Alternative? Here's What Actually Cuts Observability Costs

Key Takeaways

• Datadog costs depend on the services and contract in use: Host, ingestion, custom-metric, APM, retention, and support terms can all affect the bill. Use the current Datadog pricing and your own invoice as the baseline.
• Switching observability platforms does not automatically fix the cost problem: Migration changes both architecture and commercial terms. Compare the complete current and proposed systems rather than assuming that one pricing model is always cheaper.
• Upstream filtering is an evaluation path, not a guaranteed saving: Test a representative source, preserve required alerts and investigations, measure the output sent to Datadog, and calculate the result with your own contract.

If you are searching for a Datadog alternative, you are probably reacting to a bill that grew faster than expected. That is a rational response. But before you commit to a migration, it is worth understanding why the bill grew and which approaches actually fix it long-term.

This post breaks down Datadog’s cost structure, evaluates several alternatives, and explains how to test upstream data filtering without committing to a platform migration.

Why Datadog Bills Spiral

Datadog’s pricing looks straightforward on the surface. Infrastructure monitoring starts at $15/host/month. APM starts at $31/host/month. Log management is $0.10/GB ingested. Simple enough for a small deployment.

The problem is that these costs compound across multiple dimensions simultaneously, and every dimension grows independently.

The Per-Host Problem

Every server, container host, and VM that reports to Datadog counts as a host. Datadog measures at the 99th percentile of monthly usage, which means temporary scaling events (auto-scaling during peak traffic, CI/CD build agents, batch processing nodes) count against your bill even if they only run for hours.

A Kubernetes environment with 200 nodes that scales to 350 during peak hours gets billed for approximately 350 hosts, not 200. Add Infrastructure Monitoring at $15/host/month, APM at $31/host/month, and Security Monitoring at $10-25/host/month, and each host costs $56-71/month before a single log is ingested.

At 500 hosts: $336,000-426,000/year just for host-based fees.

The Log Ingestion Problem

Datadog charges $0.10/GB for log ingestion and $1.27/million for indexed log events. These sound cheap until you measure what a modern environment actually generates.

A Kubernetes cluster with 200 pods, each emitting 10 events per second, generates roughly 432 million events per day. A fleet of microservices with structured JSON logging can easily produce 5-10 TB/month of raw log data. Health checks, readiness probes, debug-level output, and verbose HTTP access logs make up the majority of this volume, and none of it gets queried during normal operations.

At 5 TB/month of log ingestion: $500/month in ingestion alone. At 50 TB/month: $5,000/month. Add indexed log retention and the number climbs fast.

The Custom Metrics Problem

Datadog includes a base allotment of custom metrics per host. Beyond that, pricing is $1 per 100 custom metrics per month. This sounds trivial until a team instruments a new service and adds 5,000 custom metrics. Or until high-cardinality tags (per-customer, per-endpoint, per-region breakdowns) multiply metric series by orders of magnitude.

A single Prometheus exporter with high-cardinality labels can generate tens of thousands of unique metric series. In Datadog, each series is a custom metric. Teams regularly discover that a misconfigured exporter added $2,000-5,000/month to the bill without anyone noticing.

The Real-World Bill

Here is what a mid-size Datadog deployment actually costs:

This is a conservative estimate. Real enterprise Datadog bills frequently exceed $500K-$1M/year, and some large deployments hit $3-5M/year. The problem is not that Datadog is expensive per unit. The problem is that every unit multiplies as your infrastructure grows.

The Three Approaches to Cutting Datadog Costs

When organizations search for a “Datadog alternative,” they are really searching for one of three things: a cheaper platform, a self-managed open-source stack, or a way to reduce what they send to Datadog. Each approach has different tradeoffs.

Approach 1: Switch to Another Commercial Platform

The most common reaction to a high Datadog bill is shopping for a replacement. The market offers real alternatives.

Grafana Cloud uses a consumption-based model built on open-source backends (Prometheus, Loki, Tempo). Pricing is competitive, especially for metrics-heavy workloads. The tradeoff is that you need more operational expertise. Grafana gives you components. You build the stack.

New Relic offers a user-based pricing model that looks attractive if you have many hosts but few engineers. Entity-based pricing charges per user seat rather than per host, which changes the cost curve for large infrastructure. The tradeoff: high-cardinality data and heavy log ingestion still drive costs up, just through a different meter.

Elastic Observability provides a self-managed option with no licensing fees for the open-source core. Cloud-hosted pricing depends on deployment size and storage tiers. The tradeoff is operational overhead. Running your own Elastic cluster is a full-time job at scale.

Dynatrace offers AI-assisted root cause analysis and strong enterprise governance features. Pricing is consumption-based with host units. The platform is powerful but complex to operate, and costs at scale are comparable to Datadog.

Chronosphere focuses on metrics with built-in cost controls and cardinality guardrails. If your primary concern is custom metric costs, Chronosphere addresses that directly. The tradeoff: it is metrics-focused, not a full-stack observability platform.

The honest assessment: Switching platforms trades one set of costs for another. Migration takes 6-12 months. You rebuild dashboards, monitors, integrations, and team workflows. By the time you finish, your data volume has grown enough to offset much of the savings. Platform migration makes sense when you need different capabilities (better tracing, stronger enterprise governance, specific compliance features). It rarely makes sense as a pure cost play.

Approach 2: Build an Open-Source Stack

Some teams go fully open source: Prometheus for metrics, Loki or Elasticsearch for logs, Jaeger or Tempo for traces, Grafana for visualization.

The appeal is obvious. No licensing fees. No per-host charges. No vendor lock-in. You control everything.

The reality: open-source observability requires significant engineering investment. Someone has to run the infrastructure, handle upgrades, manage storage scaling, build high availability, and maintain the integrations between components. A mid-size deployment (500+ hosts, 5+ TB/day of telemetry) typically requires 1-3 dedicated SREs just for the observability stack.

At $200K-$300K/year loaded cost per SRE, plus infrastructure costs for running the backends, the total cost of ownership for a self-managed stack often approaches what you were paying Datadog, just in a different budget line.

Open source works well for teams that already have deep Prometheus and Grafana expertise, want maximum control, and have the engineering capacity to operate their own stack. It is not a shortcut to lower costs for teams that lack that capacity.

Approach 3: Filter Data Upstream (Keep Datadog, Cut the Bill)

This approach can reduce billable volume while preserving existing Datadog workflows, but its return depends on your telemetry mix, contract, and operating costs.

Instead of replacing Datadog, you reduce what you send to it. An upstream data control plane sits between your data sources and Datadog, filtering, transforming, and routing telemetry before it hits Datadog’s meters.

The premise: if 60-80% of the telemetry hitting Datadog is noise that nobody queries (debug logs, health checks, duplicate events, verbose HTTP access logs, repetitive status messages), then removing that noise cuts your bill by 60-80% without affecting the dashboards, monitors, or workflows your team relies on.

What upstream filtering does:

• Drops low-value events at the source. Kubernetes liveness probes, load balancer health checks, and DEBUG-level logs never leave the machine. They never consume network bandwidth. They never hit Datadog’s ingestion meters.

• Samples high-volume streams. Instead of dropping all health check data, keep 1 in 60 (one per minute instead of one per second). You maintain visibility into trends without paying for every repetitive event.

• Routes data to the right tier. Security events and application errors go to Datadog at full fidelity. Raw debug logs go to S3 at $0.023/GB/month instead of Datadog at $0.10/GB. Metrics that don’t need Datadog’s visualization go to a self-hosted Prometheus instance.

• Deduplicates. When the same event is captured by multiple collection agents (a Datadog Agent and a syslog forwarder, for example), upstream deduplication ensures you pay for it once, not twice.

• Reduces custom metric cardinality. Aggregating high-cardinality metrics before they reach Datadog prevents custom metric count explosions. Roll up per-request metrics into per-minute summaries. Your dashboards still show the trends. Your custom metrics bill stays flat.

The Expanso product is purpose-built for this pattern. A lightweight agent runs on each source machine. It connects to 50 input types, processes data through 80 processors, and routes to 55 output destinations, including Datadog’s Logs API with proper tagging, compression, and batching, typically reducing API calls by 90% and ingestion costs by 60-80%.

How Upstream Filtering Works with Datadog

Upstream filtering does not replace Datadog. It sits in front of it. Your Datadog account, dashboards, monitors, and integrations stay exactly as they are. The only thing that changes is how much data reaches Datadog and at what cost.

Architecture

[Data Sources] --> [Upstream Agent] --> [Datadog API] --> [Datadog Platform]
                        |
                        +--> [S3 / Azure Blob]    (cold archive)
                        +--> [Kafka]               (streaming)
                        +--> [Prometheus]           (self-hosted metrics)

The upstream agent runs alongside your existing Datadog Agent or replaces it, depending on your deployment. It handles all collection, processing, and routing. Datadog receives only the high-value telemetry that your team actually uses for monitoring, alerting, and investigation.

What Gets Filtered

Based on production deployments, here is where the volume reduction typically comes from:

The result: Datadog receives 15-25% of the original volume, consisting of the events that actually matter for monitoring and incident response. The remaining 75-85% is either dropped (pure noise), sampled (low-value but worth trending), or routed to cheaper storage (available if needed, not burning premium ingestion budget).

Case Study: Financial Services

A global bank running Datadog across 800+ hosts was spending $1.8M/year on observability. Their audit found:

• 28% of log volume was Java application debug logging left enabled in production
• 19% was Kubernetes health check and probe responses
• 14% was duplicate events from overlapping collection agents
• 11% was verbose HTTP access logs from API gateways

After deploying upstream filtering, their effective Datadog ingest dropped by 67%. Annual spend fell to $720K, saving $1.08M/year. Their mean time to detect (MTTD) actually improved because analysts were searching through less noise. Teams focused on data observability and monitoring saw faster dashboards and more responsive alerting.

Case Study: SaaS Platform

A SaaS company with 1,200 hosts across multiple cloud regions was hitting $2.4M/year in Datadog costs. Custom metrics from high-cardinality Prometheus exporters accounted for 40% of the bill.

Upstream aggregation rolled per-request metrics into per-minute summaries before they reached Datadog, reducing custom metric series by 85%. Log filtering removed health checks and verbose access logs. Total cost dropped to $890K/year, a 63% reduction. The company kept every Datadog dashboard and monitor unchanged.

Comparing the Three Approaches

For some environments, upstream filtering can offer a favorable ratio of savings to effort. Validate that hypothesis against a representative workload and confirm that monitors, investigations, and retention requirements still work before expanding. If you later decide to migrate away from Datadog or diversify across multiple backends, evaluate the required destinations as part of the same test. This is fundamentally a data orchestration problem.

What About Datadog’s Built-In Cost Controls?

Datadog offers several features to help manage costs. They are worth using, but they operate at the wrong point in the pipeline.

Log Exclusion Filters. Datadog lets you exclude logs matching specific patterns from indexing. This reduces indexed log costs but not ingestion costs. The data still reaches Datadog, still gets processed, and still counts against your ingestion meter. You pay less for storage, but the ingestion bill stays the same.

Custom Metrics Governance. Datadog provides visibility into custom metric volumes and lets you set limits. This helps prevent runaway cardinality but does not reduce costs from legitimately needed metrics. If you need 50,000 custom metrics, governance tools help you track them, not reduce them.

Commitment Plans. Annual commitments with Datadog reduce per-unit costs by 15-25%. This helps if your volume is stable. If your volume is growing 25-40% year over year (which is typical), you outgrow your commitment tier and pay overage rates on the excess.

Sensitive Data Scanner. Datadog scans ingested logs for PII and redacts or hashes it. Useful for compliance, but it runs after data reaches Datadog. You have already paid for ingestion before redaction happens. Upstream redaction strips PII before data leaves the source, which is both cheaper and more secure for teams with strict data governance requirements.

These features can be used alongside upstream filtering. Compare both approaches using the same billable-volume baseline and contract terms; filtering at the source may also reduce network transfer and upstream processing, while destination controls may be simpler to operate.

Getting Started: A Practical Roadmap

If your Datadog bill is higher than you want and you need a plan, here is a step-by-step approach that works:

Week 1-2: Audit Your Data

Before changing anything, measure what you are sending to Datadog and who is using it.

• Pull your Datadog usage reports. Identify the top 20 log sources by volume, top custom metric namespaces, and host count trends over the past 6 months.
• For each high-volume log source, ask the owning team: when did you last query this data? Does any monitor or alert depend on it?
• Check for debug logging enabled in production. This is the single most common source of waste.
• Identify duplicate collection paths where both a Datadog Agent and another collector (Fluentd, Filebeat, a custom sidecar) send the same data.

Most teams discover that 60-80% of their Datadog volume is low-value data that no dashboard, monitor, or investigation depends on.

Week 2-4: Pilot Upstream Filtering

Deploy upstream filtering on your highest-volume, lowest-value log sources first. Typically this means:

1. Debug and trace-level application logs
2. Kubernetes health check and probe responses
3. Load balancer access logs for known-healthy endpoints
4. Duplicate events from overlapping collectors

Even filtering just these categories delivers measurable ingest reduction. Track your Datadog usage dashboard daily to see the impact.

Month 2-3: Expand and Optimize

Roll out upstream filtering across the rest of your environment. Add:

• Custom metric aggregation to reduce high-cardinality series
• Multi-destination routing to send cold-tier data to S3 instead of Datadog
• Sampling rules for high-volume streams that need partial visibility

At this point, compare the pilot and expanded-rollout baselines. Volume and bill effects will vary by data mix and by the terms of your Datadog contract.

Month 3+: Renegotiate

Sustained lower usage puts you in a stronger position to renegotiate your Datadog commitment. Show 90 days of reduced ingest data. Your account team will work with you on a commitment tier that matches your actual usage.

Bottom Line

The search for a Datadog alternative is often a search for lower costs. The fastest path to lower costs isn’t replacing the platform: it’s controlling what the platform receives. Filter the noise before it hits Datadog, route low-value data to cheap storage, and keep Datadog for the high-signal data your team actually queries. The platform stays. The bill shrinks.

If you want to quantify how much of your Datadog spend is going to data nobody queries, book a data consultation with Expanso. We’ll analyze your telemetry sources, identify the noise, and model the savings for your specific environment.

Related Articles

• What Is an Observability Pipeline?
• SIEM Cost Comparison: Why Your Bill Keeps Growing
• How to Reduce Splunk Costs Without Losing Visibility
• Splunk Pricing in 2026: The Real Cost and How to Control It
• Splunk Edge Processor vs Upstream Data Control

FAQ

How much does Datadog actually cost per year?

Datadog costs vary dramatically based on host count, log volume, and which products you use. A small deployment (50 hosts, minimal logs) can run $30,000-50,000/year. A mid-size deployment (500 hosts, 5-10 TB/month of logs, APM enabled) typically costs $300,000-500,000/year. Large enterprise deployments with 1,000+ hosts, heavy log ingestion, custom metrics, and security monitoring regularly exceed $1-5M/year. The primary cost drivers are host count (for infrastructure and APM fees) and log volume (for ingestion and indexing fees). Custom metrics with high-cardinality tags can add significant cost that is hard to predict.

What is the best Datadog alternative for cost savings?

The best approach depends on your situation. If you need different capabilities (better tracing, enterprise governance, open-source flexibility), evaluate Grafana Cloud, New Relic, Elastic, or Dynatrace against your specific requirements. If your primary goal is cost reduction while keeping existing workflows, test upstream data filtering against your own billable-volume baseline. The result depends on your data profile, contract, and the amount of data your team can safely filter, sample, aggregate, or route elsewhere.

Can I reduce Datadog costs without switching platforms?

Yes. Three strategies can be evaluated within an existing Datadog deployment: use log exclusion filters to reduce indexed log volume; implement custom metric governance to control cardinality; and review commitment tiers for predictable pricing. Upstream filtering is another option, but verify its volume and cost effects under your contract and regression-test dashboards, monitors, and integrations before rollout.

Is Grafana Cloud cheaper than Datadog?

Grafana Cloud and Datadog use different pricing models, so either can be less expensive for a particular workload. Compare current quotes using your host count, telemetry volume, retention, and required services, and include migration work such as rebuilt dashboards and team training.

How long does it take to see cost savings from upstream filtering?

The time to measurable ingest reduction depends on access to representative data, approval of filtering rules, and the scope of the pilot. Define the baseline and acceptance checks before deployment, then report the observed timing and confirm how lower usage affects the next bill under your contract.

Will filtering data break my Datadog monitors and dashboards?

No, if done correctly. Upstream filtering targets data that no monitor, dashboard, or alert depends on. The audit step (Week 1-2 in the roadmap above) identifies exactly which data sources are referenced by your Datadog configuration. High-value events, such as errors, security alerts, and application metrics that drive dashboards, continue flowing to Datadog at full fidelity. Only low-value noise (debug logs, health checks, duplicates, verbose access logs) gets filtered or routed elsewhere. Most teams report that dashboard performance actually improves because Datadog processes less data overall.

Should I switch from Datadog to open-source observability?

Moving to an open-source stack (Prometheus, Loki, Grafana, Jaeger) eliminates licensing fees but introduces significant operational overhead. Running a production observability stack at scale typically requires 1-3 dedicated SREs, plus infrastructure costs for compute, storage, and networking. At $200K-$300K/year per SRE, the total cost of ownership can approach what you were paying Datadog, just in a different budget line. Open source makes sense if your team already has deep expertise in the tools, you want maximum control over your data, and you have the engineering capacity to maintain the stack long-term. It does not make sense as a shortcut to lower costs for teams that lack that capacity.

Does upstream filtering work with Datadog’s API?

Yes. Upstream filtering integrates with Datadog through the Datadog Logs API, Metrics API, and Traces API. The Expanso product provides native Datadog output with proper tagging, compression, and batching optimized for efficient ingestion. Events arrive in Datadog with all expected metadata, tags, and formatting. From Datadog’s perspective, the data looks identical to what a Datadog Agent would send: there is just less of it.

How does upstream filtering compare to Datadog’s log exclusion filters?

Datadog’s log exclusion filters operate after data reaches Datadog. The data has already been ingested and counted against your meter. Exclusion filters reduce indexing costs but not ingestion costs. Upstream filtering operates at the data source, before data leaves the machine. Noise never reaches Datadog, never consumes network bandwidth, and never counts against any meter. The difference is significant: upstream filtering reduces your total Datadog bill, while exclusion filters only reduce the indexing portion. For log-heavy environments, ingestion can represent 30-50% of the total log management cost.