New Relic Pricing: Should You Move Off Per-User Seats?

In September we argued that New Relic pricing is really a seat argument: $349 a month for a full platform user on Pro, forty cents a gigabyte for data, and the org chart as the cost lever. On the user model that still holds.

There is now a second model with no seats at all. Unlimited users, and an invoice built from compute capacity units burned by queries, dashboards, API calls and alert evaluations. Teams ask us at renewal whether to take it.

Our answer, on a regulated account, is not yet. Three of those four meters are a person choosing to do something, and people can be managed. The fourth runs on its own, scales with the alert coverage a regulator asked you to have, and has no published price.

What are the two New Relic pricing models now?

Data plus users is the September post's model: gigabytes ingested plus billable users. The other is data plus core compute, which New Relic's pricing and billing documentation calls "consumption-based pricing for full-stack observability capabilities with unlimited users", billed "based on Core Compute Capacity Units (Core CCUs) consumed to successfully run actions such as queries, alerts, API calls, and page loads".

The same page says where it sits: "Since Core Compute is currently in Preview, if you're interested in trying the pricing model, you should reach out to your New Relic account executive." It is not a toggle in the billing screen. It arrives as a quote, written by somebody who has seen your usage and knows you have not.

What does a compute capacity unit actually count?

New Relic's pricing definitions are short and worth reading literally. A compute capacity unit is "compute capacity consumed for a successfully-run action, including loading a page, executing a query, evaluating an alert condition, and invoking an API call".

Three of those four are somebody doing something: a dashboard gets opened, a query gets run, an integration calls the API. Those you can shape.

Then there is "evaluating an alert condition", which nobody initiates. It runs on the cadence you set months ago, all night, whether an engineer is awake or not. It is the only one of the four whose volume you cannot reduce without reducing coverage.

Which of your consumption is not optional?

The alert evaluations, and on a regulated account that is not a turn of phrase.

The RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 are plain in paragraph 111: the NBFC "shall put in place a system for regularly monitoring the audit trails and system logs to detect, understand or recover from any unauthorised activity or attack". Our read of the whole direction is in what the 2026 directions change for an NBFC on AWS.

Nothing in that text prices an alert condition, and nothing in it lets you delete one to shrink a month's invoice. On the seat model the fortieth alert rule is free; the only argument about adding it is whether it will page somebody for nothing. Put a meter under it and the budget and the coverage have opposed defenders.

We would rather not build that meeting into a payments account. Same instinct as being careful about what a cost tool is allowed to touch: a control you are obliged to keep should not join the list of things somebody can trim to hit a number.

What is the core CCU rate?

As far as we can find, there is not one in public. New Relic's usage plan documentation carries the list rates, and the compute line in it reads "Advanced Compute: Advanced Compute Capacity Unit (CCU): $0.606". Advanced compute is the add-on for the AI features, not the model that replaces seats. There is no core CCU figure beside it.

So the estimate we built in September is not available here. That one worked because both halves were knowable: published rates, and your own list of names. Here you have a unit with no published price and a consumption volume you have never measured. Two unknowns, a renewal date, and only one you can close yourself.

Would you block an engineer's dashboard at 2am?

The control is called compute user limits. The documentation offers "daily or monthly budgets for individual users", and then the sentence to read twice: "When a user reaches their allocated budget, you can block their access to dashboards, query builder, and API calls until the end of the budget period or until you increase their budget."

Think about when one person's consumption spikes. During an incident. Six dashboards open, twenty ad hoc queries, the API hit from a notebook, because something is broken and the reporting window is already running. A daily budget with blocking on fires at precisely that moment.

So: monitor only for anybody who can be paged, no exceptions. Keep the hard block for service accounts and analytics users, where a stop is the behaviour you want. The same page offers monitor-only, so this is a choice, and somebody has to check it after every onboarding.

One thing we do not know and would ask before signing: how an API call is counted when it comes from automation. If you manage alert conditions in code, an apply that reconciles three hundred conditions looks like three hundred actions by the definition above. Get that answer into the order, not an email.

What happens to a consumption meter on a volume plan?

The usage plan page sets the buying programs out, and they matter more here than they ever did with seats. On the volume plan, usage above your "Licensed Monthly Quantities" is "invoiced monthly at the corresponding rates". On the savings plan you prepay a commitment fee that depletes as you consume, and from the day after "full depletion of the Commitment Fee" the program "will convert from the Savings Plan to New Relic Pay As You Go".

Seat overage has a ceiling: you cannot have more billable users than you have people. A meter has no ceiling. One team shipping an alert pack, one dashboard left on a screen in an empty room, one chatty integration, and the add-on invoice is real money. Prepay against a figure you guessed in month one and the deposit can run dry in month seven.

The usage queries will not settle it either; they are approximate by New Relic's own account. Same gap we took apart in whether your cost dashboard matches your invoice.

What can you run on Monday?

Twenty minutes in the query builder. New Relic records its own usage in the NrConsumption and NrMTDConsumption event types, and the usage queries page says those do not count towards your ingest. Start with the compute series:

FROM NrConsumption SELECT sum(consumption)
  WHERE metric = 'CoreCCU' SINCE 3 months ago TIMESERIES 1 day

Swap CoreCCU for AdvancedCCU to see what the AI and advanced analytics features are burning, if anyone has switched them on.

If your account is on the user model, the CoreCCU series will probably come back empty. Treat that as the finding, not a broken query: you cannot price this model from your own history, so ask for the preview on a non-production account for a month before anybody quotes you.

Then the number you would be trading away:

FROM NrMTDConsumption SELECT latest(FullPlatformUsersBillable)
  SINCE 3 hours ago

Put both on one page with three counts you can pull from the UI in ten minutes, because these are what the meter reads: how many alert conditions exist and on what evaluation window, how many dashboards auto-refresh, and which systems hold an API key. The same page warns the queries are approximate, so use them to locate consumption rather than to project a bill.

When is compute pricing the honest answer?

Two cases, and the first is strong enough that we expect to recommend this model to somebody inside a year.

When access is the bottleneck rather than consumption. A sixty-person org where forty people sit on basic seats and cannot open the APM screens pays for it in slower incidents and in every question routed through the five who can see. On the user model, fixing that costs $349 a head. Modest consumption, large headcount: the meter wins.

When the seat rules have already caught you. A full platform user downgraded and re-upgraded twice in a contract year is billed as full platform for the rest of it, as the first post set out. Pay a year of seats because somebody rotated a login with the on-call roster, and a model with no seats looks very attractive.

Where it is wrong is the shape we see most often on regulated accounts: a small platform team carrying a large alert surface, around the clock, because a direction says the monitoring has to be there. On seats that bill is four or five full platform users and flat. On a meter it is driven by the one thing nobody is allowed to cut. The billing unit decides this, the way hosts against active series decides Grafana against Datadog.

The short version

Run the CoreCCU and AdvancedCCU queries this week, with the full platform user query next to them. If CoreCCU comes back empty, ask for the preview on a non-production account instead of asking for a quote.

Count your alert conditions and their evaluation windows before you read any compute proposal. That number, not your headcount, is what this model prices, and the one you are least free to change.

Do not prepay against consumption you have not watched for three months. Do not arm compute user limits with blocking on anyone who can be paged. Get the API-call counting rule in writing, in the order.

And stay on seats while the core CCU rate is something you have to phone somebody to learn. A price nobody publishes is a price you cannot benchmark, and on a regulated account predictability is most of what you are buying.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.