For New Relic organizations on the New Relic One pricing model, several factors impact your costs: which edition you're on (Standard, Pro, or Enterprise), how many billable users you have, and how much data you ingest. This resource will help you estimate your New Relic data ingest costs.
Best option: extrapolate usage from a test New Relic account
Data ingest rates can vary from one New Relic organization to the next, based on what kinds of things are monitored, what features are used, the monitored applications' behaviors, and more. Given that variability, the best option is to set up a test New Relic account and then extrapolate your usage from that. If you can't or don't want to set up a test account, use the cost estimator spreadsheet.
Here are some tips for extrapolating usage from a New Relic account:
If you’re just signing up to New Relic, consider creating a test installation with an environment similar to what you’ll need moving forward. Then use the baseline ingest from the trial to extrapolate what your full environment would require. To do this, create a new free account, and use our instant observability options to get started reporting data. Note that APM, infrastructure monitoring, and logs tend to produce the bulk of most customer's data, but that can vary.
If you don't wish to create a test New Relic account, you can use our cost estimator spreadsheet. To get started, make a copy of this Google spreadsheet. The instructions below will give you instructions on how to fill out the spreadsheet, which will auto-populate an estimated cost. Note that the spreadsheet provides you only an estimate: it is not a binding billing proposal.
To arrive at the ingest rates used in the estimator, we analyzed about 10,000 existing New Relic organizations of various sizes to arrive at the ingest rates used in our calculations. Note that you get 100 GBs of data ingest per month for free.
The following sections explain how to use the various parts of the spreadsheet.
Ingest rates are measured per agent, not per host. You might have multiple agents monitoring a single host.
In the APM data volume section of the spreadsheet, you estimate whether you have low, medium, or high ingest rates from APM agents. We’ve built an average of the data volume for all APM agent types into the spreadsheet calculator. When filling out this section, consider these questions:
How many APM agents will you deploy?
What types of applications will you monitor? Understanding how the application is used and the application complexity is important. For example, e-commerce apps will have much higher throughput than an internal application.
Will you use features that contribute to higher ingest rates? See the criteria questions that follow for more detail.
Criteria for calculating ingest rates per APM agent
In general, use higher ingest rates for applications that are integration/business tiers, large business-to-consumer (B2C) sites, or have significant custom instrumentation or metrics. That means, select High in these cases:
For app behaviors and environments where you expect high throughput and a high number of errors, and the app is in a production environment.
For complex app architectures (for example, a single front-end request spawns multiple back-end requests).
If you have a high number of key transactions.
If you have custom instrumentation and APM metrics.
For transactions with a lot of attributes.
Add APM agent ingest to the spreadsheet:
Add the number of APM agents that you will monitor.
Approximate the amount of ingest you’ll need for your agents and select one of the options. In general, if you’re on the Standard pricing edition (the edition new organizations start at), you can probably select Low:
Sizing your infrastructure monitoring data ingest depends on the number of agents and integrations you have, and how much data they're each reporting.
When calculating the volume of your infrastructure ingest, take into account:
How many infrastructure agents do you think you'll need?
Which integrations contribute to higher ingest rates? The following are some approximate sizes. You should also take the size of your environments into account. If they’re very large, for example, these rates might not be accurate.
Add infrastructure agent ingest to the spreadsheet:
At step 3 in the spreadsheet, input your estimated number of infrastructure agents. To determine this, decide how many hosts you’ll run infrastructure agents on.
At step 4, assign a size for the volume of your infrastructure:
Start with your base ingest rate as Low if you'll have only a few on-host integrations.
Adjust to medium or high depending on how many and how high the volume of your integrations. Consider whether you have cloud integrations with large footprints, or a large number of database on-host integrations, or multiple or large Kubernetes clusters. For example:
If running two or more low or medium impact integrations such as cloud or on-host integrations, choose Medium ingest rate.
If running all three types of integrations (oh-host, cloud, containers) or observing really large Kubernetes environments, choose High for your ingest rates.
For this section, you add an estimated amount of ingest in gigabytes.
When estimating log data ingest:
Use current logs volume. For example:
Pull information from existing ELK, Splunk, or Sumo storage and divide by total months that data is currently retained to get a per-month rate.
Multiply your average log file size by the number of logs you use, and extrapolate to get a per-month rate.
Subtract security (PCI/HIPAA) and audit logs.
Generally, 40-50% of current ELK, Splunk, and Sumo storage is used for troubleshooting.
Understand your retention requirements.
Typically, troubleshooting logs are not that valuable after 30 days of retention.
In section 5, add your estimated monthly log data ingest, in GB. You can estimate this as 40-50% of your existing ELK (Elasticsearch, Logstash, Kibana), Splunk, or Sumo data ingest.
You can adjust the baseline data retention settings for each data source. To learn about retention and the baselines, see Data retention.
Retention considerations:
For each additional month (30 days) of retention, the cost is $0.05 per GB ingested per month.
Retention is added evenly across all namespaces up to a maximum of 395 days. Retention cannot be extended for just one namespace (for example, just logs or custom events). The increased rate is applied to all ingested data.
In section 6 of the spreadsheet, select the additional months of retention that you want.
View the calculated estimate
When you complete the extended retention section, the total estimated price is displayed in the Calculations section of the spreadsheet.
Other potential data ingest costs
Because this billing calculation was designed for newer customers, it uses the implementations and costs that our newer customers often have. For example, we haven’t provided cost estimates for browser monitoring, mobile monitoring, network performance monitoring, or other services. (Maybe worth noting: neither our basic alerting features nor our synthetic monitors contribute to data ingest.) For many organizations, these other costs will often represent only 5% or so of the costs examined and calculated in the spreadsheet. But be aware that high levels of data ingest by other tools can make that higher.
Other billing factors
Data ingest is one billing factor for New Relic One pricing. To learn about others, see New Relic One pricing.
