New Relic AI Monitoring logo

New Relic AI Monitoring Review (2026)

LLM monitoring layered onto New Relic's APM platform, billed on data ingested - which is close to the worst possible meter for verbose agent traces. One reported deployment went from $1,400 to $12,000 a month after turning it on.

Researched

Rating

2.0

Starting Price

$0.40/GB ingested

Free Plan

Yes

SDKs & Frameworks

7

Deployment

3

Best For

Organisations already standardised on New Relic for APM, logs, Kubernetes and SRE workflows, running relatively low-volume LLM features, who need correlation more than evaluation.

Last Updated:

10 Things You Should Know About New Relic AI Monitoring

  1. 1 Billing runs on three separate meters - data ingested, user seats, and compute units (CCUs) for AI features
  2. 2 Enabling New Relic AI or Transaction 360 starts the CCU meter, which tracks usage by people rather than systems
  3. 3 Free tier includes 100 GB per month of ingest, one full platform user and unlimited basic users
  4. 4 Ingest is $0.40/GB, or $0.60/GB with Data Plus
  5. 5 Full platform users are $99 each on Standard capped at 5, or $349/user/month on Pro with annual commit
  6. 6 A reported agent stack ingesting 4 TB/month grew from $1,400/mo to $9,500-$12,000/mo after AI Monitoring
  7. 7 AI Monitoring is layered on the APM 360 data model

Pros & Cons

Pros

  • If New Relic is already your observability platform, LLM telemetry correlates with APM, logs, Kubernetes and infrastructure in one place
  • The 100 GB per month free ingest allowance is genuinely large compared with most free tiers
  • Basic users are free and unlimited, which keeps read-only access cheap across a big organisation
  • Applied intelligence and the SRE agent bring mature incident tooling that AI-native vendors do not have
  • OpenLIT can feed it, so you are not locked into New Relic's own instrumentation

Cons

  • Billed on data ingested, and LLM traces are enormous - prompts, completions, tool-call payloads and retrieved context push a single trace to 5-50 KB
  • A third meter, compute units, starts when you enable AI features and tracks usage by people rather than systems
  • One reported agent stack ingesting 4 TB/month went from a $1,400/mo APM bill to $9,500-$12,000/mo once AI Monitoring volumes counted
  • Vendr data reportedly puts even 5-20 user deployments at $30,000-$80,000 per year
  • No output-quality evaluation at all - no faithfulness, relevance or hallucination scoring, no annotation or dataset curation
  • Built on the APM 360 data model, whose span shape suits HTTP and DB calls rather than multi-turn conversations and agent loops

Features

LLM and AI agent monitoring including token usage and model behaviour
Single view for troubleshooting, comparing and optimising prompts and responses
Applied intelligence grouping related alerts and surfacing anomalies
SRE agent for automated incident investigation
Correlation with the full New Relic APM, logs, Kubernetes and infrastructure stack
50+ integrations across the AI ecosystem

The meter is the problem

New Relic AI Monitoring is a competent product attached to the wrong billing model for the workload it monitors.

New Relic bills on data ingested. Ingest runs at $0.40 per GB, or $0.60 with Data Plus. That is a perfectly sensible meter for APM, where a span records a method call, a status code and some timings.

LLM traces are not like that. A single trace carries the prompt, the completion, tool-call payloads and retrieved context, and routinely runs 5 to 50 KB. RAG applications logging large retrieved-context blocks sit at the top of that range.

Charging per gigabyte for the most verbose telemetry in software is a structural mismatch, and the reported consequences are severe. One agent stack ingesting 4 TB per month reportedly went from a $1,400 monthly APM bill to between $9,500 and $12,000 once AI Monitoring volumes were counted. Vendr’s 2026 data reportedly shows even 5 to 20 user deployments landing at $30,000 to $80,000 per year.

We report these as third-party figures rather than measurements we took. But they are consistent with how the meter works, and we would treat them as a warning rather than an outlier.

The third meter nobody accounts for

This one is genuinely easy to miss, and we have not seen it flagged in any comparison.

New Relic charges on three separate meters: data ingested, user seats, and compute units (CCUs) for AI features. Enabling New Relic AI or Transaction 360 starts the CCU meter.

The subtlety is what CCUs track. They measure usage by people, not by systems. Consumption scales with how much your team interacts with the AI features, not with your application traffic. Every cost model we have seen built for New Relic accounts for ingest and seats and stops there.

If you are budgeting this product, ask your account team explicitly how CCUs will be consumed under your intended usage pattern, and get the answer before you enable the feature rather than after.

Seats, and the one genuinely good part of the pricing

MeterRate
Ingest$0.40/GB, or $0.60/GB with Data Plus
Basic usersFree, unlimited
Core users$49/user/mo
Full platform users$99 each on Standard (capped at 5), or $349/user/mo on Pro
CCUsMetered separately once AI features are on

The free tier is genuinely generous on one axis: 100 GB per month of ingest, one full platform user and unlimited basic users. Compared with Datadog’s 40,000 LLM spans, 100 GB is a lot of room to evaluate.

Unlimited free basic users is the other real strength. In a large organisation where many people need read access to dashboards and few need to configure anything, this keeps the seat cost far more contained than per-seat competitors like LangSmith.

It monitors. It does not evaluate.

This is the second thing that should decide it for many teams.

There are no output-quality evaluation metrics. No faithfulness scoring, no relevance scoring, no hallucination detection with actual machinery behind it. No annotation workflow. No dataset curation.

New Relic’s marketing references identifying quality issues including hallucination, bias and toxicity, and critics have noted the gap between that framing and what is actually implemented. What you get is monitoring - token usage, cost, latency, prompt and response capture, model comparison. Those are useful. They tell you what your system did and what it cost. They do not tell you whether the answer was correct.

If evaluation matters, you are buying a second platform regardless, which changes the economics of buying this one at all.

The APM data model shows through

AI Monitoring is layered on APM 360, so LLM workloads inherit a data model built for HTTP requests and database calls.

That model assumes a unit of work that starts, does something, and finishes. Multi-turn conversations, tool calls and agent loops do not have that shape - their natural unit is a session, not a span. You can make it work, but you are fitting a new problem into an old container, and the ergonomics suffer. Tools designed for agents from the start, like HoneyHive, model sessions natively.

Reducing the bill costs you the data

Worth understanding before you assume sampling will save you.

Because the meter is volume, you reduce cost by sending less - truncating prompts and completions, dropping retrieved context, sampling traces. The bill falls proportionally.

The problem is that the retrieved context you dropped is usually exactly what you need to debug a RAG failure. Datadog’s tail-based sampling is smarter here: it keeps every error and slow request while dropping successful fast traffic, so you lose the boring traces and keep the interesting ones. Trimming payload size degrades every trace uniformly, including the ones you will need.

If you must run this, decide early and deliberately what you genuinely need to retain.

Should you use it?

Use New Relic AI Monitoring if your organisation is already standardised on New Relic for APM, logs, Kubernetes and SRE workflows, your LLM volume is modest, and correlation with infrastructure matters more than evaluating output quality.

Don’t use it if you run high-volume or RAG-heavy workloads where trace payloads are large, you need output-quality evaluation, or you are choosing an observability platform fresh.

Bottom line: the right answer for an existing New Relic shop with light LLM usage, and an expensive mistake for almost everyone else. The ingest meter is structurally wrong for LLM telemetry, the CCU meter is easy to miss entirely, and there is no evaluation capability at all. If you are not already committed to New Relic, Langfuse, Logfire or a dedicated eval platform will serve you better for less.


Pricing structure and the three-meter model verified against published documentation and third-party analyses on 31 July 2026. The bill-increase figures and Vendr deployment costs are third-party reports, not our measurements, and are flagged as such. This is a researched directory entry - we have not yet instrumented this platform with our reference application.

Pricing Plans

Free

$0

  • 100 GB per month of data ingest
  • 1 full platform user
  • Unlimited basic users
Most Popular

Standard

Usage-based

  • Ingest at $0.40/GB, or $0.60/GB with Data Plus
  • Basic users free, core users $49/user/mo
  • Full platform users $99 each, capped at 5
  • Compute units (CCUs) metered separately for AI features

Pro

$349/user/mo

  • Full platform users at $349/user/mo on annual commit
  • Unlimited full platform users
  • Ingest and CCU meters still apply

Enterprise

Custom

  • Volume commitments
  • Contact sales

SDKs & Frameworks

Python Node.js Java Go .NET Ruby OpenTelemetry / OpenLIT ingest

Deployment

Cloud SaaS only No self-host 50+ integrations across the AI ecosystem

Eval Methods

Prompt and response comparison Cost and performance analysis Applied intelligence anomaly detection No faithfulness, relevance or hallucination scoring

Billing Unit

Data ingested (GB) plus seats plus compute units

Our Verdict

New Relic AI Monitoring makes sense for exactly one buyer - the organisation already committed to New Relic - and is a poor choice for anyone else. The correlation story is real, and the applied intelligence and SRE agent tooling is more mature than anything the AI-native vendors offer. But two structural problems dominate. First, the billing meter is data ingested, and LLM traces are among the most verbose telemetry in existence - prompts, completions, tool payloads and retrieved context routinely make a single trace 5 to 50 KB. Charging per gigabyte for that is close to the worst possible fit, and one reported deployment saw its bill go from $1,400 to between $9,500 and $12,000 a month after AI Monitoring volumes were counted. Second, it does not evaluate anything. There is no faithfulness, relevance or hallucination scoring, and no annotation or dataset curation. It tells you what your LLM did and what it cost, not whether the output was any good. If you need evaluation, you are buying a second tool regardless.

Similar Tools

Frequently Asked Questions

What is the third meter people miss?

Compute units, or CCUs. New Relic charges on three separate dimensions - data ingested, user seats, and CCUs for AI features - and enabling New Relic AI or Transaction 360 starts the CCU meter. The subtle part is that CCUs track usage by people rather than by systems, so consumption scales with how much your team interacts with the AI features rather than with your traffic. Most cost models people build for New Relic account for ingest and seats and miss this entirely. If you are budgeting, ask your account team explicitly how CCUs will be consumed by your intended usage pattern.

Why is ingest-based billing so bad for LLM workloads?

Because LLM traces are unusually large. A single trace carrying the prompt, the completion, tool-call payloads and retrieved RAG context can run 5 to 50 KB - orders of magnitude more than a typical HTTP or database span. When you are billed per gigabyte, verbosity is the cost driver, and LLM applications are the most verbose thing you can instrument. This is structurally the opposite of the problem with per-span billing, which punishes agents for span count. Here you are punished for payload size, and RAG applications with large retrieved-context blocks are hit hardest.

How bad does the bill actually get?

The reported figures are striking. One agent stack ingesting 4 TB per month reportedly grew from a $1,400 per month APM bill to between $9,500 and $12,000 per month once AI Monitoring volumes were counted - roughly a 7 to 8x increase from adding LLM telemetry to an existing deployment. Vendr's 2026 data reportedly shows even small deployments of 5 to 20 users landing at $30,000 to $80,000 per year. We are reporting these as third-party figures rather than verified measurements, but the direction is consistent with how the meter works, and we would treat them as a serious warning rather than an outlier.

Does it evaluate output quality?

No, and this is the second reason to be careful. There are no evaluation metrics for output quality - no faithfulness, relevance or hallucination scoring - and no annotation or dataset curation workflows. It does monitoring, not evaluation. New Relic's marketing references identifying quality issues such as hallucination, bias and toxicity, but critics note the absence of actual scoring machinery behind that. The practical consequence is that if evaluation matters to you, New Relic AI Monitoring is not a complete solution and you will be running a second platform alongside it.

What is the problem with the APM data model?

AI Monitoring is layered on APM 360, so LLM workloads inherit a data model designed for HTTP requests and database calls. That span shape works well for a request that begins, does something and ends. It fits badly around multi-turn conversations, tool calls and agent loops, where the natural unit of analysis is a session rather than a span. You can make it work, but you are fitting a new problem into an old shape, and it shows in the ergonomics. Tools built for agents from scratch, such as HoneyHive, model sessions natively.

Is there any way to make it cheaper?

Sampling and payload trimming, both of which cost you the thing you instrumented for. You can reduce what you send - truncate prompts and completions, drop retrieved context, sample traces - and the bill falls proportionally because the meter is volume. The trouble is that the retrieved context you dropped is usually exactly what you need to debug a RAG failure. Unlike Datadog, whose tail-based sampling can keep all errors while dropping successful traffic, trimming payload size degrades every trace uniformly. If you must use New Relic, invest early in deciding what you genuinely need to retain.