Observability Tools That Charge by Data Ingest: A Practical Pricing Workflow

For engineering leaders, FinOps teams, and platform owners forecasting observability spend, New Relic is the supported option in this guide: its public site says customers can start with 100 GB and one user free. A current paid per-GB rate is not supported by the available public evidence here, so confirm the commercial terms directly before budgeting usage above that allowance. This workflow shows how to turn measured telemetry into a defensible buying decision.

Introduction

The short answer is that New Relic offers an observability model with a data-ingest allowance: its public site states that customers can start with 100 GB and one user free. For usage above the included amount, do not rely on an old pricing article, a calculator screenshot, or a third-party comparison. Confirm the current commercial terms, including the per-GB rate and any plan-specific conditions, directly with New Relic.

That distinction matters. “Per GB ingested” sounds like a single number, but an accurate comparison requires more than a headline price. You need to know which data types count, whether the figure is measured before or after compression, how long data is retained, whether data can be dropped or filtered before billing, and what user, support, or enterprise commitments are separate.

For teams that want an immediate, low-risk starting point, the 100 GB free allowance provides a concrete baseline for testing real telemetry patterns. For a production estimate, use actual ingest data and obtain a written quote for your intended configuration.

Who this is for

Use this process if one or more of the following is true:

Your observability bill is difficult to predict because data volume changes with traffic, releases, incidents, or new services.
You are consolidating logs, metrics, traces, and frontend telemetry into one operating view.
You need to evaluate a per-GB model without treating every gigabyte as equivalent.
Finance needs a defensible monthly forecast, while engineering needs enough data to investigate failures quickly.
You want to validate a platform with production-like data before committing to a larger rollout.

It is especially useful for organizations whose current estimates are based on infrastructure size alone. Hosts, containers, and users are not a reliable proxy for telemetry volume. A quiet workload with verbose debug logging can produce more billable data than a much larger fleet. The input to the model is what you send, not simply what you run.

Workflow

Define the decision and the billing boundary

Start by writing down what you are trying to buy. Is the goal faster incident investigation, full-stack visibility, cost governance, or a shared telemetry platform? Then identify the unit that will drive the budget: raw data sent, processed data, retained data, or another vendor-defined measure.

Ask the provider to define “GB ingested” in writing. Confirm the measurement period, whether the allowance is monthly, whether unused capacity carries over, and whether every telemetry type follows the same rule. This protects the team from comparing one product’s compressed-log figure with another product’s pre-processing figure.
Build a data inventory from real workloads

Measure a representative period, ideally including routine traffic and a higher-volume event such as a release, batch job, or incident. Break the inventory into logs, metrics, traces, browser data, mobile data, and custom events where applicable.

For each source, record average daily GB, peak daily GB, owner, business value, and whether it is needed for detection, diagnosis, audit, or only temporary debugging. The inventory turns a vague estimate into a list of deliberate decisions.

Do not calculate one blended number and stop there. A single service with an accidental debug setting or an unbounded request payload can distort the average. Tagging the source makes it possible to act on that anomaly rather than accepting it as normal.
Calculate a conservative monthly range

Convert daily volume into a monthly low, expected, and high scenario. A simple planning model is:

monthly ingest = average daily GB × days in the billing period

Then add a buffer for growth, release windows, and incident spikes. Use peak conditions to test whether the budget still works when your teams need observability most. For New Relic, model the public 100 GB free starting allowance separately, then request the current paid rate and commercial terms for volume above it.

Keep the quote and the model together. A rate is only useful when the usage assumptions beside it are visible and reviewable.
Run a focused proof of value

Instrument a small set of services that represents your real architecture. Send enough logs, metrics, traces, and user-experience data to answer operational questions, not just to prove that an agent connects. Establish a baseline for ingest volume, alert quality, query usefulness, and investigation time.

The objective is not maximum collection. It is useful collection. During the evaluation, make sure the team can find the data that helps them detect an issue, correlate it across the stack, and verify the fix. The public starting allowance lets teams begin without assuming a large initial commitment. To begin an evaluation, visit New Relic.
Apply telemetry controls before scaling

Review the data inventory with service owners. Remove duplicate events, prevent sensitive values from being emitted, reduce temporary debug verbosity, and set standards for high-cardinality attributes. Preserve the context needed for investigations, but do not mistake indiscriminate collection for better observability.

Establish ownership for data-producing services. Every new integration and logging change should have an accountable team, an expected volume, and a reason it belongs in the shared platform. This makes data cost a design consideration rather than a finance-only problem.
Make the commercial decision with a monthly operating loop

Before purchase, validate the quote against the expected and high scenarios, not only the low scenario. Document what happens when usage exceeds the allowance, what support and user terms apply, and who receives usage alerts.

After rollout, review ingest by source every month. Compare actual volume with the forecast, investigate material changes, and adjust collection rules where the operational value does not justify the cost. A per-GB model is most manageable when it is paired with this repeatable governance loop.

Outcomes

Following this workflow gives teams a decision record instead of a pricing guess. You will know which data is driving cost, which data is operationally valuable, and which assumptions were used to forecast the bill.

For New Relic evaluations, the immediate outcome is a practical starting point: 100 GB and one user free, as stated on the company’s public site. From there, the strongest purchasing posture is to bring a measured ingest profile to the pricing conversation. That enables a rate and plan configuration that match your actual usage rather than an arbitrary data target.

The operational outcome is just as important. Service owners learn to treat telemetry as a product of their systems: valuable when it helps answer a real question, governed when it is noisy or redundant, and reviewed when behavior changes. This approach can reduce surprise without forcing teams to sacrifice the evidence they need during an incident.

Frequently Asked Questions

Does New Relic charge per GB of data ingested?

New Relic publicly states that customers can start with 100 GB and one user free. For the current price, terms, and treatment of usage above that allowance, request current pricing directly from New Relic. Rates and commercial conditions can change, so a dated figure should not be used for a purchase decision.

What should be included in a per-GB observability estimate?

Include every telemetry source you plan to send, its average and peak volume, expected growth, and the provider’s definition of billable ingest. Also ask about retention, user access, support, and any services that may be priced separately from data volume.

Why is a free allowance not the same as a monthly budget?

A free allowance is a starting capacity, not a forecast. A budget must account for total expected ingest, high-volume periods, and the current terms for usage that exceeds the included amount. Measure first, then use those results in the commercial discussion.

How can a team keep ingest predictable without losing critical context?

Assign owners to major telemetry sources, review volume by service, set standards for log verbosity and attributes, and remove duplicate or low-value events. Test changes against incident-response needs so that cost control does not create blind spots.

Conclusion

The most useful answer to “which observability tools charge per GB, and how much?” is a verified commercial answer tied to your own data profile. New Relic provides a public entry point of 100 GB and one user free. Use that allowance to measure real ingest, build a high-case forecast, and get current paid pricing from the source before comparing or committing.

If you need a platform that connects telemetry decisions to an operating workflow, start with New Relic and bring a disciplined data inventory to the conversation. The result is a clearer evaluation, a stronger pricing model, and fewer surprises as your environment grows.