The model: two axes instead of one
New Relic bills for two things at once. The first is data coming in: the first 100 GB per month are free, and beyond that it is billed per GB, at a higher rate on Data Plus, which adds longer retention and some capabilities.
The second is users. Basic users cost nothing but can only look. A full platform user — the one who can actually investigate — is paid for separately, and the price rises with the plan.
Publishing the prices is a real merit and worth saying: you can do the maths before signing, which is not always the case in this market. The problem is not transparency, it is what those two axes do in Kubernetes.
The first axis: nobody decides the GBs
A hundred free gigabytes sounds like a lot. A Kubernetes cluster with the Prometheus exporters installed as they ship consumes it in days, and not because of logs.
The reason is the number of distinct metrics. Every label combination counts as a separate series, and labels accumulate: service name, namespace, version, node, response code. One metric with four labels of ten possible values each is ten thousand series, and each one reports its value every few seconds.
Adding a pod identifier to a metric that already had three labels multiplies the total by the pod count — a number that in Kubernetes changes on its own, without anyone approving it.
So the axis that drives the bill is not your user traffic or the size of your business. It is a configuration decision someone made to debug something months ago and nobody reverted.
The second axis is the one that really hurts: who gets to look
Billing per seat means spend grows with hiring rather than with usage: the tenth engineer costs the same as the first even if they log in twice a month. And on call, the person who needs to investigate is whoever is on shift, not whoever holds the assigned seat.
The consequence shows up on call. When full seats are expensive they get rationed, and then the person on duty at three in the morning may not have the seat they need to investigate. They have to wake up someone who does.
That cost appears on no invoice, but it is what stretches incidents out: time to resolution stops depending on the tool and starts depending on who got the licence.
It is also the hardest spend to cut, because cutting it means taking access away from someone who was using it.
What Moonin replaces and what it does not
Moonin does not bill per seat. The price depends on cluster size, so whoever needs to look, looks — including the person on duty at three in the morning. That is what it replaces in the New Relic model, and it is not a pricing detail: it is an operational difference.
On data, Moonin does not compete on volume. It answers two questions: what changed in the cluster and what broke afterwards. For that it keeps a resource inventory, a revision history per service with image and commit, DORA metrics computed from that history, and service-to-service traces with eBPF, without instrumenting code.
What it does not do: it is not an instrumented APM, it has no dashboard engine for arbitrary charts, and it does not ingest or search logs at scale. If the value you get from New Relic is NRQL queries over your own business data, that is not replaced.
When Moonin is not the answer
If you use New Relic as a telemetry database — sending your own application events and querying them with NRQL to answer business questions — that is a legitimate use case and Moonin does not cover it. It is not a general-purpose data platform.
If your team is small and fits in the free tier, there is nothing to optimise. A hundred gigabytes and one free full seat are enough for a modest cluster, and competing with free makes no sense.
And if the real problem is that nobody cleaned up cardinality, switching tools hides it instead of fixing it. Dropping unnecessary labels reduces a New Relic bill without migrating anything, and it is worth trying first.
How the maths compares
Moonin bills for the size of what you are running: one Compute Unit is 1 vCPU or 2 GB of RAM, and the larger dimension is billed, never the sum. A cluster with 120 vCPU and 180 GB of RAM pays for 120 units, because 120 vCPU beats 90 RAM units.
The price drops in tiers, and each tier is billed at its own rate: the first 100 units at USD 20, units 101 to 250 at USD 18, units 251 to 500 at USD 15, and above 500 negotiated. A 300-unit cluster pays 100 × 20 plus 150 × 18 plus 50 × 15, which is USD 5,450 per month.
What that number does not include is a per-person charge. Ten engineers or forty cost the same, because what is billed is the infrastructure observed, not access permissions.
And it does not depend on how much data your metrics generate, so adding a label to debug something has no consequence on the bill.
How to migrate without going blind
Install the Moonin chart on one cluster and leave it running in parallel for two or three weeks without turning anything off. Access to the Kubernetes API is read-only and does not interfere with the New Relic agent.
Then look at your New Relic usage summary and separate two things: how many GB come from cluster infrastructure metrics, and how many from your own application data. The first part is what a deployment history usually makes redundant; the second is not.
With that you can decide concretely which integrations to turn off and how many full seats you actually need, instead of negotiating blind at renewal.
See whether it applies to you
Two numbers say almost everything: how many GB you ingest per month and how many full seats you are paying for. If the second number made you ration access, there is something to fix there.
Moonin pricing per Compute Unit · See Moonin on a real cluster, no form