Cut Datadog, New Relic & Splunk Costs (2026)

Look at any mid-sized SaaS company's cloud bill in 2026 and you'll spot something weird: observability is often the second-largest line item, and sometimes it beats AWS itself. I've seen a company running a $400k/month AWS bill routinely burn $250k–$600k on Datadog, and Splunk licenses in regulated enterprises can easily clear seven figures a month. The culprit is almost never "we got more users." It's cardinality explosion, unsampled logs, and those per-host SKUs that cheerfully scale alongside your auto-scaling groups.

So, this is the playbook I wish someone had handed me three years ago — a practical guide to cutting observability spend by 40–70% without blinding your on-call engineers. Every recommendation below comes with working config, real 2026 pricing math, and the specific trade-offs that have tripped up the teams I've worked with.

Why Observability Costs Exploded in 2026

Three structural forces are pushing bills to record highs right now:

Kubernetes cardinality. Every pod restart mints a brand-new pod_name tag value. On a fleet of 5,000 pods cycling daily, that's about 150,000 unique time series per metric per month — and Datadog custom metrics alone will bill you $60,000+ if you leave it unbounded.
AI workloads. LLM gateways, vector databases, and model-serving fleets emit 10–100x more logs than traditional services (prompt/response pairs, embedding distances, token counters), and most teams ship them raw with zero sampling.
Per-host pricing on ephemeral infrastructure. Datadog, New Relic, and Dynatrace all charge per billable host-hour. An autoscaling group that spins up a Graviton instance for 11 minutes still bills as a full host on many SKUs. Yes, really.

The good news? Every one of these cost drivers has a concrete, code-level fix. Let's walk through them vendor by vendor.

Datadog Cost Optimization

1. Slash Custom Metric Cardinality

Datadog's 2026 pricing sheet lists custom metrics at $0.05 per 100 time series per month (Pro plan), with 100 included per host. In nearly every environment I've audited, the single biggest bill driver is high-cardinality tags on custom metrics — user_id, request_id, trace_id, dynamic pod_name, and unbounded HTTP route patterns.

Find your worst offenders first. The Metrics Summary API is your friend here:

# Find metrics with the highest cardinality — these are your biggest cost drivers
curl -X GET "https://api.datadoghq.com/api/v2/metrics?filter[configured]=true&window[seconds]=86400" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" | \
  jq '.data | sort_by(-.attributes.ingested_tags_count) | .[0:20] |
      .[] | {metric: .id, tags: .attributes.ingested_tags_count}'

Then use Tag Configurations (formerly called "metric tag configuration") to drop high-cardinality tags at ingest. Worth noting: this actually deletes them from storage, unlike exclusion filters which just hide them from dashboards.

# Configure allowed tags for a custom metric — drops everything else
curl -X POST "https://api.datadoghq.com/api/v2/metrics/checkout.orders.total/tags" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "type": "manage_tags",
      "id": "checkout.orders.total",
      "attributes": {
        "tags": ["env", "service", "region", "payment_method"],
        "include_percentiles": false,
        "aggregations": [
          {"space": "service", "time": "sum"}
        ]
      }
    }
  }'

Honestly, this is the kind of change that pays for a month of engineering time in a single afternoon. At one client, stripping user_id from six business metrics cut the custom metric bill from $47k to $8k per month. The trade-off is real but narrow: you lose the ability to slice by user directly in dashboards. You can still query individual users through logs or RUM when you actually need to.

2. Tier Your Logs with Flex Logs

Standard Datadog log indexing runs $1.27–$2.50 per million events ingested, plus another $1.70–$2.50 per million events indexed (15-day retention). Flex Logs — introduced in 2024 and expanded quite a bit in 2026 — stores logs for up to 15 months at roughly 70% less than standard indexing. The catch: you query them on-demand rather than live.

The winning pattern is pretty simple: index only what on-call needs live, and route everything else to Flex Logs.

# datadog-agent.yaml — route by log source
logs_config:
  processing_rules:
    - type: exclude_at_match
      name: drop_kube_system_debug
      pattern: '"level":"debug".*"namespace":"kube-system"'

# In the Datadog UI — Log Pipelines → Exclusion Filters:
# - Index only env:prod AND (status:error OR service:checkout OR service:auth)
# - Route env:staging and env:dev entirely to Flex Logs
# - Sample INFO logs at 10% before indexing

Pair that with Logging Without Limits sampling rules:

# Sample 10% of INFO, 100% of WARN/ERROR, 0% of DEBUG
# Applied in the pipeline UI or via Terraform
resource "datadog_logs_index" "main" {
  name = "main"

  exclusion_filter {
    name       = "sample-info-logs"
    is_enabled = true

    filter {
      query = "status:info -service:auth -service:payments"
    }

    exclusion_filter {
      sample_rate = 0.9   # drop 90%, keep 10%
    }
  }
}

Expected impact: 50–65% reduction in indexing cost, with zero loss of troubleshooting capability for production errors. That last part is what you'll need to convince SREs with.

3. Reduce APM Billable Host Count

APM is billed per host-hour, at roughly $31–$36 per host/month (annual) or $40 per host/month (on-demand). Two patterns routinely over-count hosts, and both are worth checking today:

Sidecar duplication. If you're running the Datadog Agent as both a DaemonSet and an Operator-injected sidecar, you're counting every host twice. Standardize on one pattern.
Short-lived autoscaler hosts. On clusters using Karpenter or cluster-autoscaler with aggressive consolidation, a node that lives for 12 minutes still counts as a billable hour. Consolidate to larger node sizes — one 16-vCPU node is one APM host; eight 2-vCPU nodes are eight APM hosts. The math writes itself.

For Lambda and serverless workloads, consider switching from the per-host "Serverless APM" SKU to the pay-per-invocation SKU — it's typically 60% cheaper if your functions run fewer than ~4 million invocations per host-month.

4. Control Synthetic and RUM Volumes

Browser RUM sessions are billed at $1.80 per 1,000 sessions in 2026, and they can silently 10x when marketing launches a new funnel on a Friday evening (ask me how I know). Cap them explicitly in the SDK:

// Cap RUM sessions to a fixed daily budget
datadogRum.init({
  applicationId: '...',
  clientToken: '...',
  site: 'datadoghq.com',
  service: 'checkout-web',
  sessionSampleRate: 25,           // Only track 25% of sessions
  sessionReplaySampleRate: 5,      // Only replay 5% of those
  trackUserInteractions: true,
  defaultPrivacyLevel: 'mask-user-input',
});

New Relic Cost Optimization

New Relic switched to ingest-based pricing back in 2020, and refined it again in 2025. You now pay $0.35 per GB ingested (Original Data Option) or $0.55 per GB (Data Plus), with full-stack and compute consumption billed separately. The optimization levers are pretty different from Datadog, so don't assume the same playbook applies.

1. Drop Attributes Before Ingest

Every event in New Relic carries attributes, and those attributes balloon your payload size. Use drop rules via NerdGraph to kill them at the ingest layer. This is pre-bill, so the savings show up immediately:

# Drop noisy, high-cardinality attributes from Logs
mutation {
  nrqlDropRulesCreate(
    accountId: 1234567,
    rules: [
      {
        action: DROP_ATTRIBUTES,
        nrql: "SELECT stack_trace, request.headers.cookie, request.headers.authorization FROM Log WHERE service = 'checkout' AND level != 'ERROR'",
        description: "Remove PII + stack traces from non-error checkout logs"
      },
      {
        action: DROP_DATA,
        nrql: "SELECT * FROM Log WHERE level = 'DEBUG' AND env != 'production'",
        description: "Drop all debug logs outside production"
      }
    ]
  ) {
    successes { id rule { nrql } }
    failures  { error { description } }
  }
}

2. Tune Infrastructure Agent Sampling

Out of the box, the New Relic Infrastructure agent ships 20+ events per host per minute. On large fleets, that becomes a serious ingest line. Knock it down in newrelic-infra.yml:

license_key: ${NR_LICENSE_KEY}

# Stop shipping metrics every 15s — every 60s is enough for most hosts
metrics_network_sample_rate: 60
metrics_storage_sample_rate: 60
metrics_system_sample_rate: 60
metrics_process_sample_rate: -1   # disable per-process samples entirely

# Drop noisy events
custom_attributes:
  environment: "${ENVIRONMENT}"

# Disable if you don't use the inventory feature (most teams don't)
disable_cloud_metadata: false
inventory_refresh_seconds: 3600

On a 2,500-host fleet I worked with, tuning those sample rates cut New Relic Infrastructure ingest from 3.1 TB/month to 0.9 TB/month. That's a $770 → $315/month line item, and that's before dropping per-process metrics.

3. Right-size User Seats

New Relic splits users into Basic, Core, and Full Platform tiers. Full Platform seats run $99–$549/month each, which adds up fast. Audit NrAuditEvent and LoginEvent to find the inactive ones:

-- NRQL query — find Full Platform users with no activity in 30 days
SELECT uniques(actor.email)
FROM NrAuditEvent
WHERE userType = 'FULL_USER'
AND timestamp < (now() - 30 days)
SINCE 90 days ago
LIMIT MAX

Downgrading 40 inactive Full Platform seats to Basic saves roughly $20k/month. It's also one of the most politically painless wins — nobody fights for a login they haven't used in three months.

Splunk Cost Optimization

Splunk Cloud is licensed on daily ingest volume (GB/day) or — increasingly in 2026 — on Workload Pricing (SVC, aka Splunk Virtual Compute). Enterprise on-prem is still ingest-based. The single biggest Splunk lever is reducing what you send, and the second is searching less inefficiently. In that order.

1. Filter and Route with Edge Processor

Splunk Edge Processor (which ships with the open-source OpenTelemetry Collector under the hood) lets you filter, route, and sample at the source — before data ever hits your ingest license. This is, by a decent margin, the highest-ROI change available in a Splunk environment today.

# edge-processor-pipeline.yaml — OTel config running in Edge Processor
receivers:
  filelog:
    include: [/var/log/app/*.log]
    start_at: end

processors:
  # Drop debug logs from non-prod
  filter/drop_debug:
    logs:
      log_record:
        - 'severity_text == "DEBUG" and resource.attributes["env"] != "prod"'

  # Sample INFO logs to 10%
  probabilistic_sampler:
    hash_seed: 22
    sampling_percentage: 10

  # Redact PII before shipping
  transform:
    log_statements:
      - context: log
        statements:
          - replace_pattern(body, "[0-9]{13,19}", "[REDACTED_CARD]")
          - replace_pattern(body, "[\w.+-]+@[\w-]+\.[\w.-]+", "[REDACTED_EMAIL]")

exporters:
  splunk_hec:
    endpoint: https://hec.splunkcloud.com:443/services/collector
    token: ${SPLUNK_HEC_TOKEN}
    # Route low-value logs to cheaper S2 storage instead
  splunk_hec/archive:
    endpoint: https://hec-archive.splunkcloud.com:443/services/collector
    token: ${SPLUNK_ARCHIVE_TOKEN}

service:
  pipelines:
    logs/prod:
      receivers: [filelog]
      processors: [filter/drop_debug, transform]
      exporters: [splunk_hec]
    logs/sampled:
      receivers: [filelog]
      processors: [probabilistic_sampler]
      exporters: [splunk_hec/archive]

2. Use SmartStore with Tiered Indexes

SmartStore decouples compute from storage, letting you keep hot data on SSD and warm/cold data in S3. Most environments I've looked at index everything to hot by default — which is exactly the wrong thing to do. Push low-search-frequency data to cold:

# indexes.conf — tier by access pattern
[audit_logs]
homePath   = $SPLUNK_DB/audit_logs/db
coldPath   = $SPLUNK_DB/audit_logs/colddb
thawedPath = $SPLUNK_DB/audit_logs/thaweddb
# Audit logs rarely searched — move to cold after 7 days
maxHotSpanSecs = 86400
maxDataSize    = auto
frozenTimePeriodInSecs = 31536000

# Enable SmartStore — coldPath goes to S3
remotePath = volume:remote_store/audit_logs

[volume:remote_store]
storageType = remote
path        = s3://splunk-smartstore-prod/indexes
remote.s3.access_key = ${AWS_ACCESS_KEY_ID}
remote.s3.secret_key = ${AWS_SECRET_ACCESS_KEY}

3. Kill Expensive Scheduled Searches

Workload Pricing meters SVC usage, and long, inefficient scheduled searches quietly burn thousands of dollars a month. Audit them like this:

| rest /services/saved/searches splunk_server=local
| eval last_run = strftime(dispatch.latest_time, "%Y-%m-%d")
| where disabled = 0 AND cron_schedule != ""
| table title, search, cron_schedule, dispatch.earliest_time, dispatch.latest_time
| join title [
    search index=_internal sourcetype=scheduler earliest=-7d
    | stats avg(run_time) as avg_runtime_s,
            sum(run_time) as total_runtime_s,
            count as run_count by savedsearch_name
    | rename savedsearch_name as title
  ]
| sort - total_runtime_s
| head 20

In most environments, the top 20 scheduled searches account for 60–80% of scheduler load. Convert them to summary-indexed accelerated data models, or rewrite with tstats instead of search. You'll often see a 50–100x speedup. Sometimes more.

Cross-Vendor: Use OpenTelemetry as Your Cost Lever

If I had to pick just one piece of advice from this whole guide, it would be this: the most durable observability cost strategy in 2026 isn't vendor-specific. It's standardizing on OpenTelemetry (OTel) as your instrumentation layer.

OTel is vendor-neutral. That means:

You can filter, sample, and redact once in the Collector and hit multiple backends simultaneously.
You can migrate between Datadog, New Relic, Splunk, Honeycomb, Grafana Cloud, or self-hosted without re-instrumenting a single application.
The threat of migration alone is a powerful negotiating lever at contract renewal. Enterprises that moved 20% of ingest to a secondary vendor typically see 25–40% discounts when they renew.

Here's a minimal multi-backend OTel Collector config to get you started:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 50000
    policies:
      - name: keep-errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: keep-slow
        type: latency
        latency: {threshold_ms: 1000}
      - name: sample-rest
        type: probabilistic
        probabilistic: {sampling_percentage: 5}

  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  datadog:
    api: {site: datadoghq.com, key: ${DD_API_KEY}}
  otlphttp/grafana:
    endpoint: https://otlp-gateway.grafana.net/otlp
    headers: {Authorization: "Basic ${GRAFANA_TOKEN}"}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, batch]
      exporters: [datadog, otlphttp/grafana]

Tail-based sampling at the Collector routinely cuts trace ingest by 90–95% while preserving 100% of error and slow traces. Which, let's be honest, are the only signals anyone actually looks at during an incident.

A 30-Day Observability Cost Reduction Plan

Week 1 — Measure. Pull the last 90 days of your observability bill by SKU. Identify your top 5 cost lines. Run the Datadog, NRQL, and Splunk cardinality audits above.
Week 2 — Cardinality. Apply tag configurations, drop rules, and attribute drops for the top 10 high-cardinality metrics. Measure the impact before moving on.
Week 3 — Logs. Implement exclusion filters, sampling, and Flex Logs / SmartStore / Edge Processor routing for non-critical log sources. Keep error and audit logs at 100%.
Week 4 — Hosts and seats. Consolidate node sizes to reduce billable host count. Audit user seats and downgrade inactive Full Platform users.

Teams that execute this plan with any real discipline typically cut observability spend by 40–60% in the first month, with another 10–20% available through OTel migration and contract renegotiation over the following quarter. That's not hypothetical — that's the median result I've seen.

Frequently Asked Questions

How much does Datadog actually cost per host in 2026?

List price sits at roughly $15–$23 per host/month for Infrastructure Pro, plus $31–$40 per host/month for APM, plus custom metric overage at $0.05 per 100 time series. In practice, most mid-sized environments land somewhere between $45–$90 fully loaded per host/month before log and RUM costs. Annual commitments typically knock 25–35% off list.

Is OpenTelemetry really a viable replacement for Datadog or New Relic?

OpenTelemetry replaces the instrumentation and collection layer, not the backend. You still need a backend (Datadog, New Relic, Grafana Cloud, Honeycomb, or self-hosted Tempo/Loki/Mimir) to store, query, and visualize. The real value is that OTel makes the backend swappable — which means you can actually shop pricing at contract renewal without re-instrumenting your apps.

What's the fastest win for cutting Datadog costs?

Custom metric cardinality, almost every time. Audit your top 20 metrics by ingested_tags_count, apply Tag Configurations to keep only 3–5 low-cardinality tags, and drop the rest. Most teams see a 30–50% reduction in the custom metric line within 48 hours of applying this.

Should I self-host observability instead?

Self-hosting Prometheus + Grafana + Loki + Tempo on Kubernetes is cheaper at ingest levels below ~1 TB/day. But total cost of ownership flips once you factor in on-call burden, HA storage, retention tuning, and specialist engineering time. Self-hosting tends to make financial sense for very large environments (>5 TB/day ingest) and regulated setups with strict data residency requirements. Below that, managed SaaS with aggressive cardinality and sampling controls usually wins on TCO.

How do I justify observability cost cuts to SREs who resist losing signals?

Frame the conversation around signal-to-noise ratio, not cost. Every dashboard, alert, and saved view should have a named owner and a documented purpose. Run a quarterly "observability garage sale" — if nothing queries a metric or log source for 90 days, delete it. SREs generally come around once they understand that 95% sampling on 200 OK traces plus 100% retention on errors and slow traces actually preserves every signal they use on-call.