Here’s a question worth asking before your next renewal: if you doubled your engineering team tomorrow but changed nothing about your infrastructure, should your observability bill go up?

Under the dominant pricing model, it does — sometimes a lot. That’s not an accident or a bug. It’s the shape of how most observability tools are sold, and once you see the shape, you can’t unsee it. This post is about that shape: who charges this way, why it’s rational for them, when it’s actually fair, and what it looks like when the bill tracks your infrastructure instead of your org chart.

The dominant model: per user, per host, plus data

Open the pricing page of almost any major observability vendor and you’ll find some combination of three meters:

Per host / per node. You pay for each monitored host, agent, or node. This one is defensible — it roughly tracks how much you run.
Per active user / per seat. You pay for each person who logs in. Grafana Cloud, for example, meters active users on its paid tiers; Datadog layers per-seat charges on products like APM, CI, and its security suite.
Per data volume. Ingested logs, custom metrics, retained spans, indexed events. This is the meter that quietly balloons.

None of this makes Grafana or Datadog bad products. They’re excellent — Grafana is the best visualization layer in the industry, and Datadog’s breadth is genuinely useful if you’re monitoring VMs, serverless, databases, and Kubernetes from one pane. The critique here isn’t quality. It’s that two of those three meters — seats and data — are only loosely correlated with the value you get, and tightly correlated with your team’s growth and chattiness.

A quick note on numbers before we go further: vendor pricing changes constantly and varies by plan, region, and negotiation. As of writing, published per-user tiers for hosted observability tend to start somewhere in the low-to-mid tens of dollars per user per month, and host-based tiers in a similar range per host. Treat every figure in this post as illustrative — check the vendor’s current pricing page for real quotes. The argument doesn’t depend on the exact dollar amount. It depends on the slope.

Same cluster, two teams: where the bill diverges

Let’s make it concrete. Imagine two companies running the exact same infrastructure: one production cluster, 10 nodes, a steady volume of logs and metrics. The only difference is the size of the team touching it.

Company A is a 3-person team. Three logins, three seats.
Company B is a 30-person team. Same cluster, but platform engineers, backend devs, on-call rotation, and a couple of managers all have access.

Under a per-user model, Company B pays for the same 10 nodes plus 10x the seats. Their system is no more complex. Their infrastructure bill from the cloud provider is identical. But their observability bill diverges — not because they’re monitoring more, but because more humans can see the dashboards.

Here’s the perverse part: Company B is doing the right thing. You want more engineers looking at production. You want the junior dev to check a dashboard before asking, the backend engineer to self-serve a trace instead of pinging the on-call, the whole rotation to have real access during an incident. Per-seat pricing puts a price tag on exactly that behavior — so teams ration logins, share accounts (against the ToS), or quietly decide that observability is a privilege for the few. That’s a bad outcome dressed up as cost control.

The economics: why incumbents charge this way (and won’t stop)

It’s tempting to read per-seat pricing as greed. It’s more useful to read it as rational vendor design.

Seat-based pricing has three properties a public-company revenue model loves. It’s predictable — seats grow slowly and stickily, so revenue is forecastable. It’s expansion-friendly — as a customer’s team grows, revenue grows automatically, with zero extra sales effort (“net revenue retention” is the metric investors reward). And it’s legible — a CFO understands “$X per person” instantly, even when the underlying value is data volume.

For a broad, generalist platform, this even has a fairness logic: a 30-person company probably does extract more total value from a do-everything observability suite than a 3-person shop. The vendor is, in a rough sense, pricing to value.

The point isn’t that this is evil. The point is that it’s structural. A vendor whose revenue is built on seats and data volume cannot switch to pricing purely on your infrastructure without blowing a hole in its own forecast. So it won’t — and that’s the right call for them. It’s just worth knowing that the model optimizes the vendor’s revenue predictability, and your headcount-driven bill is a side effect, not a target.

What KubeBolt charges: per resource

KubeBolt takes the third meter — the honest one — and drops the other two.

We price per resource: your bill tracks the infrastructure you actually run, the nodes and workloads under management. It does not track how many people log in. Inviting your whole team costs nothing extra. The 30-person company and the 3-person company running the same cluster pay the same, because they’re running the same thing.

Two more facts that follow from this, both live today, not “coming soon”:

The open-source agent is free forever under Apache 2.0 — unlimited clusters, unlimited nodes, unlimited users, on your own infra. Bring your own AI key and the Copilot is unlimited too.
The hosted tier has a free plan available now, so you can run KubeBolt Cloud without a seat calculator in the first conversation.

Why can we do this when the incumbents can’t? Partly focus — we do one thing, Kubernetes operations, so our costs track your cluster, not a sprawling multi-signal backend. And partly because we designed the revenue model around it from day one instead of retrofitting it onto a seat-based business. A newcomer’s advantage is having nothing to protect.

The honest part: when per-user pricing does make sense

This would be a cheap post if it pretended per-seat pricing is always wrong. It isn’t. There are real cases where it’s the fairer model:

The value genuinely is per-person. For a BI tool, a design suite, or a CRM, the seat is the unit of value — each user does distinct, individual work. Charging per seat there is honest.
Tiny infra, large team. If you run almost no infrastructure but have a big organization poking at it, a per-resource model could theoretically undercharge relative to the value delivered. Per-seat captures that.
Predictability is worth more to you than fairness. Some finance teams genuinely prefer a bill that maps to headcount because headcount is easy to forecast and govern. That’s a legitimate preference, not a mistake.
Governance and access control. In regulated environments, “who has a seat” is itself a controlled list, and per-seat billing incidentally enforces access discipline.

If you’re in one of those buckets, per-user pricing may be exactly right for you. The argument here is narrower than “seats bad”: it’s that for infrastructure tooling, where the value scales with the system and not the login, headcount is the wrong meter.

Map it to your own setup

Here’s an illustrative scenario table. The numbers are made up round figures for shape, not quotes — plug in your own vendor’s real pricing to make it exact.

Scenario	Nodes	Engineers	Per-user model (illustrative)	Per-resource model (illustrative)
Small startup	5	3	~$45/mo seats + host & data	tracks 5 nodes only
Same startup, hiring	5	12	~$180/mo seats + host & data	unchanged — still 5 nodes
Scale-up	20	30	~$450/mo seats + host & data	tracks 20 nodes only
Enterprise team, flat infra	20	80	~$1,200/mo seats + host & data	unchanged — still 20 nodes

Read the rows top to bottom within a company. Under the per-user column, the bill climbs every time you hire — even when the “Nodes” number never moves. Under the per-resource column, the bill only moves when your infrastructure does. One of those columns rewards you for growing the team. The other taxes you for it.

The strategic question for you isn’t “which vendor is cheapest today.” It’s “which meter do I want my bill attached to for the next three years?” If your team is going to grow faster than your cluster — and most healthy teams do — the meter matters more than the sticker price.

If per-resource pricing is the shape you want, our pricing page lays out the tiers, including the free-forever OSS agent and the hosted free tier — no seat math required. And if you’d rather just try it, the agent installs in about a minute; invite the whole team when you’re ready. It won’t change the bill.