Whether you’ve heard it anecdotally or read the research, pricing and billing can be a barrier to observability. Software pricing and billing can be complex; that complexity can be further exacerbated when trying to compare the costs of different observability vendors with different pricing and billing models.
The best observability vendors offer transparent, budget-friendly pricing—including a low data cost per GB and reasonable costs for infrastructure, services, or users—and a low-cost entry point.
Some observability vendors seem to have affordable pricing at first glance, but they bury hidden costs, overage fees, and penalties in the contract terms. This type of bait-and-switch pricing (low entry costs but expensive add-ons) is a classic example of a pricing trap.
Watch out for these five common pricing and billing traps to maximize your observability return on investment (ROI).
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 Datadog1) 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.2
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!3
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 Datadog4, Elastic5, and Splunk6) 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.7
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.8 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.11 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.
New Relic prices its all-in-one observability platform based on just two metrics—users (one of the most stable pricing units) and data ingest (at a low cost per GB of data ingested that includes up to 90 days of data retention)—with no penalties for scaling. Because data typically grows much faster than staff headcount, doubling infrastructure and data with other vendors typically doubles your bill, while the New Relic cost would only increase by 30%, on average. Your provisioned users automatically get access to 30+ capabilities, so all your data, tools, and teams are in one place. Our usage-based billing model means you only pay for what you use (no peak billing!). And the platform includes tools to help you manage data ingest and query, track, and alert on billing-related usage.
Learn more about New Relic user- and usage-based pricing and billing and sign up for a free account to try it for yourself (no credit card required!).
View The Best Pricing and Billing Models for Observability white paper for additional details, including the top 10 pricing and billing questions to ask.
Splunk. n.d. “Splunk Usage Subscription Limits Enforcement and Entitlements.” Splunk. Accessed November 30, 2022. https://www.splunk.com/en_us/legal/usage-subscription-limits-enforcement-and-entitlements.html.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.
This blog post contains “forward-looking” statements, as that term is defined under federal securities laws, including but not limited to statements regarding the anticipated benefits and value propositions of the New Relic usage-based pricing model. The achievement or success of the matters covered by such forward-looking statements are based on New Relic current assumptions, expectations, and beliefs and are subject to substantial risks, uncertainties, assumptions, and changes in circumstances that may cause New Relic actual results, performance, or achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that could affect New Relic financial and other results and the forward-looking statements in this post is included in the filings New Relic makes with the SEC from time to time, including in the most recent New Relic Form 10-Q, particularly under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations.” Copies of these documents may be obtained by visiting the New Relic Investor Relations website at http://ir.newrelic.com or the SEC website at www.sec.gov. New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law.
All third-party trademarks (including logos and icons) referenced by New Relic remain the property of their respective owners. Unless specifically identified as such, New Relic’s use of third-party trademarks does not indicate any relationship, sponsorship, or endorsement between New Relic and the owners of these trademarks. Any references by New Relic to third-party trademarks are to identify the corresponding third-party goods and/or services.