An observability bill does not grow with what you use. It grows with how what you use gets counted. Kubernetes makes that worse than anywhere else, and not all of the spend is fixed by switching tools.
Datadog bills infrastructure per host, roughly USD 15 to 23 per month depending on plan, and APM separately at roughly USD 31 to 40 per host. With a fixed number of servers that is predictable and even reasonable. In Kubernetes the number is not fixed.
Autoscaling creates nodes on demand and shuts them down afterwards. But every node that existed during the month is counted, even one that lived for three days. A cluster averaging 40 nodes that peaks at 120 during a launch does not pay for 40: it pays for something much closer to 120.
That is why the bill is hard to budget. What drives the cost is how many nodes existed, and nobody decides or watches that number: autoscaling produces it on its own. Nobody approved spending more; the spend appeared because the system did its job.
Plans include around 100 custom metrics per host. Beyond that each metric is billed at roughly USD 0.05 per month. That sounds small, and it is, until you understand what counts as a distinct metric.
To Datadog, every label combination is a separate metric. If you measure a service latency and label it with the service name, the namespace and the version, that is already several. Add the pod identifier and the count multiplies by however many pods exist at that moment — and in Kubernetes that number changes on its own.
One metric with four labels of ten possible values each is ten thousand distinct metrics. The usual Prometheus exporters, installed as they ship, produce tens of thousands.
This is the spend that surprises people, because no purchase caused it. What caused it was a configuration line someone added to debug a problem and nobody removed afterwards.
Ingestion is billed by volume, around USD 0.10 per GB. Indexing is billed separately, per million events, and rises with how many days you want to keep them. Two separate charges on the same log.
The practical consequence arrives at the worst moment: the team starts deciding what it can investigate based on what it can afford. During an incident that is exactly backwards.
Moonin answers two questions and only those, and costs less precisely because of it: what changed in the cluster, and what broke after that change. To answer them 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 collected with eBPF in the node kernel, with no code instrumentation.
What it does not do, stated plainly: it is not a general-purpose APM, it is not a dashboard engine for building arbitrary charts, and it does not replace log ingestion or search at scale. If your team lives inside hand-built dashboards, or depends on complex queries over terabytes of logs, that part stays where it is.
What usually works is not replacing everything. It is stopping per-host APM payments on the services where knowing what was deployed already answers the question, and keeping the large tool for what genuinely needs it.
If what you need is to see inside the code — CPU per function, traces with your own business annotations, errors with full stacks — an instrumented APM does something kernel traces do not. Switching there to save money gets expensive later.
If your spend is concentrated in logs rather than hosts, changing observability tools does not move it. That work is retention and sampling, and probably deciding what not to keep at all.
And if your cluster is small and stable, per-host billing is cheaper than any alternative. When the node count does not move, the arithmetic favours Datadog.
Moonin does not count hosts. It counts the size of what you are running: one Compute Unit equals 1 vCPU or 2 GB of RAM, and the larger of the two is billed, never the sum. A cluster with 120 vCPU and 180 GB of RAM pays for 120 units: 120 vCPU against 90 RAM units, so 120 wins. Not 210.
What that changes in practice is that the number does not depend on how many nodes existed or how much traffic there was. Ten nodes of 12 vCPU is 120 vCPU; twenty nodes of 6 is also 120. Same bill. Autoscaling stops having a financial consequence.
The price drops in tiers, and each tier is billed at its own rate — a single rate is not applied to the whole. The first 100 units are USD 20 each; units 101 to 250 are USD 18; units 251 to 500 are USD 15; above 500 is negotiated.
So a 300-unit cluster pays 100 × 20 plus 150 × 18 plus 50 × 15, which is USD 5,450 per month. It does not pay 300 × 15, nor 300 × 20. That includes 10 GB of storage per unit and standard support. There is no base cost and no per-cluster minimum.
The usual mistake is turning off what works before trusting what is new, and losing visibility exactly when something breaks. The reverse order is better.
First you install the Moonin chart on one cluster and let it run in parallel for two or three weeks, touching nothing you already have. That gives you a real inventory and deployment history, yours, to compare against what you are already watching.
Then you identify which part of your current spend answers questions that history already covers. This is where it usually turns out per-host APM was being used to find out what changed, not to profile code.
Only then do you reduce what is redundant, service by service, keeping the large tool where its capability genuinely cannot be substituted.
The useful conversation does not start with price. It starts with two numbers: how many nodes your cluster runs on a normal day, and how many on the worst day of the month. Those two say whether there is room or not.
About usPricingSecurity and permissionsPartner programmevs Datadogvs Prometheus & Grafanavs New Relicvs Dynatracevs ELK and ElasticsearchCrashLoopBackOffOOMKilledImagePullBackOffPod stuck in PendingDocumentationDemoSign upContact usArguz, the consultancy
In most cases no, and it is better not to pretend otherwise. Moonin replaces the part that answers what changed in the cluster and what broke afterwards, which is often a large share of per-host APM spend. It does not replace an instrumented APM for code profiling, a hand-built dashboard engine, or log ingestion and search at scale.
For three reasons that do not depend on average size. First: autoscaling creates nodes, and every node that existed during the month is counted, so a three-day spike sets a thirty-day bill. Second: every label combination counts as a distinct metric, so adding one label can multiply the total by the pod count. Third: logs are billed twice, once for storing them and once for being able to search them.
Arguz measured between 20% and 40% cloud bill reduction across its own projects, but that includes infrastructure savings and not only observability. It depends on the starting point: an environment where nobody reviewed oversizing leaves far more room than one already optimised. Anyone promising you a percentage without having seen your clusters is guessing.
No. Moonin collects service-to-service traces with eBPF in the node kernel, so there are no libraries to add, no SDK, no sidecars and no changes to your deployment pipelines. One Helm chart per cluster. That agent does need node privileges to read kernel traffic: it is the trade-off for not touching your applications, and it is documented agent by agent.
Yes, and that is the recommended way to start. Access to the Kubernetes API is read-only and does not interfere with other agents. Running both for two or three weeks is what lets you compare with your own data before reducing anything.