96% of organisations are actively cutting observability costs. The median company overspends by 30-60% on monitoring due to default configurations, unchecked data growth, and tool sprawl. The 12 strategies below are ranked by savings potential and implementation effort, drawn from real-world cost optimisation projects across hundreds of enterprise monitoring deployments.
Monitoring cost reduction does not mean monitoring less. It means monitoring smarter. Every strategy below maintains or improves your observability coverage while reducing the amount you pay for it. The key insight is that most monitoring spend is driven by data volume (logs, metrics, traces), and most of that data volume is either unqueried, duplicated, or retainable at a lower cost tier. By targeting these inefficiencies, you can reduce costs by 30-50% in 60-90 days without any loss of incident detection or debugging capability.
We have organised these strategies from quickest wins (low effort, immediate savings) to strategic initiatives (high effort, largest long-term savings). Most teams should start with strategies 1-4, which can be implemented within a sprint and typically deliver 25-40% savings. Strategies 5-8 require cross-team coordination and deliver an additional 15-25%. Strategies 9-12 are quick wins that deliver smaller but meaningful incremental savings.
| # | Strategy | Est. Savings | Effort | Applicable Vendors |
|---|---|---|---|---|
| 1 | Custom Metrics Filtering | 20-40% | Medium | All |
| 2 | Log Sampling & Filtering | 30-50% | Medium | All |
| 3 | APM Trace Sampling | 15-30% | Low | Datadog, New Relic, Dynatrace |
| 4 | Cardinality Management | 20-40% | High | Datadog, Grafana Cloud |
| 5 | Tool Consolidation | 15-25% | High | All |
| 6 | Retention Policy Optimisation | 10-20% | Low | All |
| 7 | Annual Commitments | 15-25% | Low | All |
| 8 | Open Source Migration | 40-90% | Very High | N/A |
| 9 | Exclude Dev/Staging Environments | 10-20% | Low | All |
| 10 | Use Free Tiers Strategically | 5-15% | Low | New Relic, Grafana Cloud |
| 11 | Right-Size Monitoring Agents | 10-15% | Medium | Datadog, Dynatrace |
| 12 | Implement FinOps Practices | 15-30% | Medium | All |
Custom metrics are the #1 hidden cost driver, especially in Kubernetes environments. Every unique combination of metric name and tag values creates a separate billable time series. A 50-host Kubernetes cluster with standard labels easily generates 250,000-500,000 custom metric series. On Datadog at $0.05/100 metrics above the included 100/host, that is $1,000-2,250/month in overages alone. Filtering involves identifying which tag combinations are actually queried in dashboards and alerts, then aggregating or dropping the rest at collection time. Most teams find that only 20-30% of their custom metrics drive any actionable alerts or dashboard panels.
On Datadog, enable Metrics Without Limits to aggregate tag combinations at ingestion time. Audit your Metrics Summary page to identify high-cardinality metrics. On Grafana Cloud, review your active series count and implement relabeling rules in Prometheus to drop unused labels before remote-write. On all platforms, implement a metric allowlist policy where teams must register new custom metrics and justify the tag dimensions they need.
Logs consume 50-70% of total monitoring spend for most organisations. The majority of log volume comes from a small number of high-volume, low-value sources: health check endpoints, debug-level logging left enabled in production, repetitive application framework logs, and verbose middleware logging. Filtering at source means preventing these logs from ever reaching your monitoring platform, eliminating both ingestion and indexing costs. Sampling applies to moderate-value logs that are useful for debugging but do not need to be captured at 100% volume, such as successful request logs that can be sampled at 10-25% without losing statistical significance.
Start by identifying your top 10 log sources by volume using your vendor's log analytics. For Datadog, configure log exclusion filters in the Datadog UI under Logs > Configuration > Pipelines to drop health checks, debug logs, and other noise before indexing. For all platforms, implement source-side filtering in your application's logging configuration to prevent debug and trace-level logs from reaching production log pipelines. Consider sending high-volume logs to cheap object storage (S3/GCS) for compliance while only indexing the 10-30% you actually need to search.
Most teams deploy APM with 100% trace capture enabled, which is almost never necessary and extremely expensive at scale. A single API endpoint handling 1,000 requests per second generates approximately 2.5 billion traces per month. On Datadog, beyond the 1 million included spans per APM host, additional spans cost $1.70 per million. Head-based sampling captures a configurable percentage of all traces (e.g., 10-25%), which provides statistically valid performance data for P50/P90/P99 latency analysis. Tail-based sampling is more sophisticated: it captures 100% of error traces and slow traces while sampling routine successful traces at a low rate, ensuring you never miss problematic requests.
For Datadog, configure the trace agent's DD_APM_SAMPLE_RATE environment variable to 0.1-0.25 for head-based sampling. For more control, implement Datadog's trace sampling rules to capture 100% of error traces and traces exceeding latency thresholds while sampling normal traffic at 5-10%. For New Relic, configure the newrelic.transaction_tracer.transaction_threshold to focus on slow transactions. For open-source (Jaeger/Tempo), implement tail-based sampling in the OpenTelemetry Collector.
High-cardinality labels are the #1 cost driver in metric-based monitoring systems. Cardinality refers to the number of unique values a label can take. Labels like pod_name (thousands of unique values in K8s), request_id (infinite), or user_id (potentially millions) create exponential growth in the number of metric time series, each of which is separately billed. A single metric with 5 labels, each having 100 unique values, creates 10 billion potential time series. Most monitoring platforms charge per active time series, making uncontrolled cardinality the fastest path to budget overruns. Managing cardinality requires disciplined label policies and automated enforcement.
Audit your highest-cardinality metrics using your vendor's metrics explorer or Prometheus's tsdb status endpoint. Identify labels with more than 100 unique values and evaluate whether the granularity is actually needed. Common culprits: pod_name (use deployment instead), request_path (use parameterised routes), user_id (remove from infrastructure metrics), and hostname (aggregate to cluster level). Implement label allowlists at the collection layer and set up cardinality alerts to catch new high-cardinality metrics before they impact billing.
Observability tool sprawl is endemic in mid-market and enterprise organisations. Different teams independently adopt different tools: infrastructure monitoring on one platform, APM on another, log management on a third, and alerting on yet another. Each tool has its own per-unit pricing, and overlapping data collection means you are paying multiple vendors for the same underlying telemetry. Consolidating to a single vendor or a unified open-source stack eliminates duplication, enables volume-based pricing negotiation, and reduces the engineering overhead of maintaining multiple platform integrations. The savings come from both reduced licensing costs and reduced engineering maintenance time.
Conduct a monitoring tool audit: list every tool used for observability across all teams, the annual cost of each, and the capabilities that overlap. Build a consolidation business case comparing current total spend against projected spend with a single vendor or unified stack. Common consolidation patterns: Datadog for everything (simplest but most expensive), Grafana Cloud for metrics + logs + traces (good balance), or self-hosted Prometheus + Grafana + Loki + Tempo (cheapest but highest engineering investment). Plan a phased migration over 2-4 quarters rather than a big-bang switch.
Most monitoring vendors default to a single retention period for all data, which is both too long for data you never query and too short for data you need during incidents. A tiered retention strategy matches data retention to actual query patterns: hot storage (7-15 days) for active dashboards and recent alerts, warm storage (30-60 days) for incident investigation, and cold archive (12+ months) for compliance. This tiered approach can reduce storage and retention costs by 40-60% compared to a single 30-day retention policy applied uniformly, because most monitoring data is never queried after 7 days but compliance requirements mandate longer retention.
Analyse your query patterns to determine how far back queries typically reach. Most teams find that 90%+ of queries hit data less than 7 days old. Configure tiered retention: set default retention to 7-15 days for standard metrics and logs, 30 days for APM traces and critical application logs, and route compliance-required logs to cheap object storage (S3 at $0.023/GB/month) with 12-month retention. On Datadog, use Log Archives to route logs to S3 while maintaining short indexing retention. On Grafana Cloud, configure separate retention policies per data source.
Every major monitoring vendor offers significant discounts for annual payment commitments versus month-to-month billing. Datadog offers approximately 17% savings with annual billing. New Relic offers up to 20% for annual commitments. Grafana Cloud and Dynatrace offer 15-20% annual discounts. For enterprise contracts, additional negotiated discounts of 10-25% on top of standard annual pricing are common for commitments exceeding $50,000 annually. The risk of annual commitments is being locked into a vendor at a usage level you may outgrow, but for stable deployments with predictable growth, the savings are immediate and guaranteed.
Calculate your current monthly spend and project 12-month usage. Request annual pricing quotes from your current vendor and at least one competitor. Use the competitor quote as leverage in negotiations even if you do not intend to switch. For Datadog, negotiate based on committed usage rather than peak usage to avoid overpaying for auto-scaling spikes. Time your negotiation to coincide with vendor fiscal year-end (Datadog's fiscal year ends in January) when sales teams are most motivated to close deals.
Migrating from commercial monitoring to self-hosted open source (Prometheus + Grafana + Loki + Tempo) eliminates all vendor licensing costs. For a 100-host deployment, the savings can be dramatic: from $5,000-15,000/month on Datadog to $2,000-5,000/month in cloud infrastructure costs for self-hosted. The trade-off is engineering time: initial setup requires 4-8 weeks of platform engineering work, and ongoing maintenance requires 0.25-0.5 FTE. This strategy is most effective for organisations with existing platform engineering teams and Kubernetes expertise. For teams without dedicated platform engineers, the engineering cost may exceed the vendor licensing savings.
See our detailed guide on open source vs paid monitoring TCO for a complete analysis. The typical migration path is: deploy Prometheus for metric collection, Grafana for dashboards, Loki for log aggregation, and Tempo for distributed tracing. Use the OpenTelemetry Collector as a vendor-neutral ingestion layer. Plan for 8-12 weeks of parallel running where both old and new systems operate simultaneously. Budget for dashboard recreation (the most time-consuming migration task) and team retraining.
Many organisations run the same monitoring agent on development, staging, and production environments, paying full vendor pricing for non-production hosts. Development and staging environments typically account for 30-50% of total host count but generate zero revenue-impacting alerts. Excluding or downgrading monitoring on non-production environments is a quick win that immediately reduces host-based monitoring costs by 20-40% of the non-production portion of your bill. The trade-off is reduced visibility into pre-production issues, which can be mitigated by using free-tier monitoring or lightweight open-source agents on non-production hosts.
Audit your host inventory and tag all hosts by environment (production, staging, development). For Datadog, configure the Datadog agent on non-production hosts to either not send data or send to a separate, free-tier organisation. For New Relic, non-production hosts still count toward data ingest but can use a free-tier account. Consider deploying Prometheus with short retention (2 days) on non-production environments for basic monitoring at minimal infrastructure cost.
New Relic and Grafana Cloud offer substantial free tiers that can cover significant portions of a monitoring deployment. New Relic provides 100GB of monthly data ingest free, which covers basic monitoring for up to 20-30 hosts. Grafana Cloud provides 10,000 active metric series, 50GB of logs, and 50GB of traces free. Strategic use of free tiers involves routing non-critical monitoring data (development environments, internal tools, low-priority services) to free-tier accounts while maintaining paid accounts for production-critical services. This splits your monitoring spend across paid and free tiers, reducing overall cost.
Create separate monitoring accounts or organisations for free-tier usage. Route non-critical services, internal tools, and development environments to the free tier. Maintain paid accounts for production services that require full retention, alerting, and support. Use the OpenTelemetry Collector to route telemetry to different backends based on service priority or environment tags.
Monitoring agents collect data from hosts and send it to your monitoring platform. Over-configured agents collect more data types and higher resolution metrics than necessary, increasing both the data volume billed and the compute overhead on monitored hosts. Default agent configurations typically enable all available integrations and checks, many of which generate metrics that are never queried or alerted on. Right-sizing agents involves auditing which integrations and checks are enabled, disabling those that do not contribute to active dashboards or alerts, and reducing collection frequency for non-critical metrics from the default 15-second interval to 60-second or longer intervals.
Audit your agent configuration files across all hosts. For Datadog, review the datadog.yaml and conf.d/ directory for enabled integrations. Disable integrations that do not have corresponding dashboards or alerts. Reduce the min_collection_interval for non-critical checks from 15 seconds to 60 seconds. For Prometheus, review your scrape_configs and reduce scrape_interval for non-critical targets. For all platforms, implement a quarterly agent configuration review as part of your FinOps practice.
FinOps (Financial Operations) applied to observability means treating monitoring spend as an engineering cost that requires ongoing management, not a fixed overhead. This involves establishing cost visibility (dashboards showing monitoring spend by team, service, and environment), accountability (chargebacks or showbacks so teams see their monitoring costs), and optimisation (regular review cycles to identify and address cost anomalies). Organisations that implement FinOps for observability typically achieve 15-30% sustained savings through cultural change: when teams see the cost of their monitoring decisions, they naturally optimise. The key metrics to track are cost per host, cost per service, and cost as a percentage of cloud spend.
Start with visibility: build a monitoring cost dashboard that breaks down spend by team, service, environment, and data type. Share this dashboard monthly with engineering leadership. Implement a monthly FinOps review meeting focused on monitoring costs. Set cost budgets per team and alert when teams exceed their budget. Create a monitoring cost section in your post-incident review process to capture cost impacts of incidents. Long-term, implement showback or chargeback mechanisms so that teams bear the monitoring cost of the infrastructure they own.
8 costs inflating your bill by 37-97%
Cost CalculatorCompare vendors after optimisation
Datadog PricingSpecific Datadog cost reduction tips
Open Source vs PaidThe ultimate cost reduction: migrate to OSS
Cost BenchmarksAre you overspending vs industry average?
Vendor ComparisonSometimes switching vendors is cheapest
The fastest ways to reduce your Datadog bill are: enable Metrics Without Limits to aggregate unused tag combinations (saves 20-40% on custom metrics costs), configure log exclusion filters to stop indexing health checks and debug logs (saves 30-50% on log costs), implement APM trace sampling at 10-25% capture rate (saves 15-30% on APM costs), and switch from monthly to annual billing (saves 17% immediately). Together, these four actions typically reduce a Datadog bill by 30-50% within 30 days. For larger savings, evaluate whether tool consolidation or partial migration to Grafana Cloud for logs and metrics could further reduce costs while maintaining Datadog for APM only.
Achieving 50% monitoring cost reduction requires combining multiple strategies. Start with the four highest-impact actions: log filtering and sampling (30-50% savings on logs, which are 50% of spend), custom metrics aggregation (20-40% savings on metrics), APM trace sampling (15-30% savings on APM), and annual commitment negotiation (15-25% savings across all products). If these do not reach 50%, consider migrating non-critical workloads to a cheaper vendor or free tier, excluding development and staging environments from paid monitoring, and implementing tool consolidation if you currently use multiple vendors. Most organisations achieve 50% reduction within 90 days by implementing the top 5-6 strategies simultaneously.
When implemented correctly, monitoring cost reduction does not reduce incident detection capability. The strategies focus on eliminating waste, not monitoring coverage. Log filtering removes health checks and debug noise that clutter incident investigation rather than aiding it. Metrics aggregation removes unused tag combinations that nobody queries. APM sampling at 10-25% provides statistically valid latency data for alerting while capturing 100% of error traces. Retention tiering maintains short-term hot data for active alerting while archiving older data at lower cost. The key principle is that cost reduction should target data volume and retention, not monitoring breadth. You should monitor the same services and endpoints after optimisation, just with less redundant data.
The quickest win depends on your current setup, but for most teams using Datadog or Splunk, configuring log exclusion filters delivers the fastest savings. Logs typically account for 50-70% of monitoring spend, and most teams are indexing 3-5x more log data than they actually query. Configuring exclusion filters for health check logs, debug-level logs, and high-volume middleware logs can be done in under an hour through the Datadog UI and immediately reduces indexed log volume by 40-70%. For a team spending $10,000/month on monitoring where logs are 60% of cost, reducing log indexing volume by 50% saves $3,000/month starting immediately. No application code changes required, no downtime, and the excluded logs can still be archived to S3 for compliance.