Top five observability pricing traps

Unbudgeted monthly overage fees and penalties

Subscription-based billing for enterprise software is designed to maximize committed shelfware (software that was paid for but not used). While using too little of your commit results in shelfware, using too much usually results in overage penalties. This is beneficial for vendors but not for you.

Many observability vendors include limited amounts of data ingestion, data retention, containers, custom metrics, synthetic checks, and so on as part of their bundled per-agent or lower-priced edition limits. To avoid surprise costs, it’s important to consider these limits and the costs of exceeding them when forecasting your budget.

For example, charging per container imposes a configuration burden on your engineering teams since some observability vendors (like Datadog¹) charge a premium for monitoring more than five containers running continuously on an infrastructure host, which is extremely common (most customers run 20 or more). And Splunk charges a 150% overage fee if you exceed your monthly subscription usage level for synthetic checks.²

Cheap introductory pricing with unpredictable costs as you scale is frustrating. Beware of “starting at” pricing. For example, Datadog offers a lower price if you have an annual contract, including a monthly spending commitment, and a 17–50% higher on-demand price if you don’t have an annual contract or exceed your monthly commitment. Its on-demand price for hosts is 17–20% higher and logs are up to 50% higher!³

In addition, for any pricing unit, you should be able to burst (autoscale without penalty) during seasonal spikes or unpredictable workload increases.

Tools to query, track, and alert on billing-related usage are a best practice because they make accurate sizing and pricing easier. For example, you should be able to create an alert when data usage exceeds a fixed monthly threshold for gigabytes. Unfortunately, not all observability vendors provide these tools, so ask whether they do and, if so, how. However, you shouldn’t have to establish daily quotas that you anticipate you’ll run over during peak and seasonal periods, which would result in constantly adjusting quotas.

With usage-based pricing and billing, you don’t have to predict upfront how much data you’ll use over the next year(s) or deal with shelfware if you use too little or penalties if you use too much. Choosing a usage-based pricing and billing vendor helps you avoid unbudgeted overages after spending tons of time attempting to forecast the annual spend for each SKU.

Paying for the whole month or year at your peak usage level

Another variable to consider is how the vendor handles seasonality, blue/green deployments (also known as canary deployments), and traffic spikes. Some observability vendors (like Datadog⁴, Elastic⁵, and Splunk⁶) price by high watermark (peak) usage instead of for your actual usage. In a world where infrastructure scales up and down with customer demand, charging at a peak rate is predatory, as spikes can double your bill. For example, during a winter holiday season, you may have higher usage due to greater user traffic on your frontend applications, which essentially penalizes you for success. Ideally, you should only pay for what you use instead of paying for peak usage all month.

Paying for unwanted bundles to get the capabilities you need

For observability vendors that use a bundle-of-SKUs approach, consider whether that vendor forces you to bundle adjacent use cases. This could mean that if you want just application performance monitoring (APM), you must also sign up for infrastructure monitoring. For example, Datadog requires you to have infrastructure monitoring for every billable APM host, which would increase your APM costs by the cost of the monitoring infrastructure as well.⁷

Constant re-forecasting and re-contracting for 16+ different SKUs

All major observability vendors (except New Relic) use a bundle-of-SKUs approach with up to 20 different infrastructure- and service-based pricing units (such as hosts, agents, nodes, CPU cores, and so on), which are not stable, often as committed use-it-or-lose-it monthly amounts. This complex bundle-of-SKUs approach requires you to forecast your usage based on your historical usage, which can be challenging, especially if you’re experiencing rapid growth.

This complicated forecasting process can be further frustrating when hit by surprise overages. When your monthly usage exceeds your commitment, you’ll receive an unbudgeted bill for overage fees and on-demand penalties. Just a few hours of higher traffic could double your monthly costs!

Developers constantly evolve their applications to take advantage of new technologies, shifting from on-prem to cloud, large to small virtual machines (VMs), VMs to Kubernetes (K8s), K8s to serverless containers, containers to serverless functions, and so on. As your applications and components change with each sprint, you must re-analyze, re-forecast, and re-contract each month for each SKU. This is a difficult task and inefficient use of time for most teams, so many customers are repeatedly hit with unbudgeted overage bills and constantly have to re-negotiate ever-larger contracts with these vendors. Instead, look for a pricing model that’s weighted based on stable pricing units like users.

Whereas New Relic all-in-one pricing gives you the flexibility to use any of our 30+ capabilities as your needs change, enabling full-stack observability with no cost penalties or complicated forecasting.

Data explosion doubling your bill

Data is the biggest variable cost for observability. As you shift from on-prem to cloud and microservices, there can be hundreds of small programs instead of a few large programs. Customers generally report 2–10x telemetry data increases or more. And data can double every two to three years—a data explosion. The associated network, storage, and compute costs can add up quickly.

A common challenge is that log volumes are unpredictable when it comes to forecasting costs. For example, system and user load along with unexpected code changes can cause Datadog log management costs to explode. Datadog has a complicated formula to calculate how logs are used that can add more than US$2.50–$3.75 per one million logging events for 30 days of retention. With an average of 1.5–2 GB per million events, that would be US$1.00–$2.50 per GB! That’s a lot more than the advertised data ingest rate of US$0.10/GB.⁸ Splunk charges approximately US$4.00 per GB for logs.^{9 10} Elastic charges per server in your Elasticsearch cluster and an increase of data loggings requires an increase in Elasticsearch servers.¹¹ So, doubling your data ingestion can double your cluster size and costs.

Therefore, it’s important to future-proof cloud adoption by looking for an observability vendor that offers a low data cost per GB.

And, to reduce the amount of data ingested (and data ingest bills), you should be able to manage your data ingest by configuring data-dropping rules that filter out unimportant, low-value data and potentially sensitive data.