There’s a quiet moment in every observability rollout where the incentives flip. In week one, more telemetry means more insight: the first traces answer questions you couldn’t answer yesterday. A few months later, someone opens the invoice — and from that day on, every new span is a cost decision. Teams start sampling away the data they’ll wish they had during the next incident. The tool that was supposed to create clarity now creates a budget meeting.
That’s not a pricing detail. It’s a design failure. If your monitoring bill grows with the amount of data you send, then the vendor earns more when you understand your systems worse per euro — and has no reason to help you send less.
When we designed Sluicio’s pricing, we started from the opposite premise: the data stored in a monitoring tool should be a value creator, not a problem.
What we decided
The model, in one paragraph (the full details are on our pricing page): the Community Edition is free, self-hosted, and unlimited — no cap on integrations, users, or telemetry volume. The paid Enterprise Edition adds the enterprise layer (SSO, advanced RBAC, audit log, MFA enforcement, long-term retention controls) and support. And it has exactly one meter: the number of systems and integrations you monitor in production.
Not per user — your support engineers and managers should see the same screen as your developers, and visibility shouldn’t have a tax. Not per GB or per span — you host the data on your own infrastructure, so charging you for storage you already pay for would be metering someone else’s disk. Not per host or container — scaling your infrastructure shouldn’t scale your monitoring bill. And your test, acceptance, and staging environments are included: we charge for what you run in production, not for watching it before it ships.
Why systems and integrations are the right meter
An integration in Sluicio is one flow you care about — “Orders → ERP,” “Webhook ingest → queue → warehouse.” A system is a broker, an MFT platform or database server you monitor directly as a first-class thing, with its own health checks and alerts. Together they’re the closest thing we’ve found to an honest proxy for the value the product delivers.
Here’s the reasoning. What you actually buy from a monitoring tool is not storage — it’s the confidence that a flow your business depends on will not break silently. That confidence scales with how many flows you’re protecting, not with how chatty their telemetry happens to be. Two companies can monitor the same twenty integrations while one emits fifty times more spans than the other; they’re getting the same value, and under our model they pay the same. Under a data-metered model, the second company pays fifty times more — for the crime of thorough instrumentation.
There’s a second-order effect we care about just as much: because we don’t earn anything from your data volume, we can be genuinely on your side of the cost equation. Every plan includes a usage report that shows exactly what you’re storing, and we actively encourage filtering, sampling, and aggregating at the Collector — sending the signal and dropping the exhaust. A vendor paid by the gigabyte can’t write that sentence without a conflict of interest. We can, because when you halve your storage bill, our revenue doesn’t move.
The hard part: keeping this promise in the cloud
Today Sluicio is self-hosted, and the model above is almost easy: you host the data, so there’s nothing for us to meter. But a managed cloud version is on our roadmap, and we want to be upfront about the tension that creates — because in a SaaS, we pay for the storage, the ingest, and the queries. The entire industry’s answer to that tension is the per-GB meter, and it’s exactly the model we’ve been arguing against.
We’re not going to pretend the tension away; we’re going to engineer around it. Our intent is that cloud pricing stays anchored to the same meter — systems and integrations — and that we make the underlying data cost manageable the same way we help self-hosted customers manage theirs: sensible retention defaults with configurable windows, aggregation and tiering of older telemetry, and tooling that continuously flags what you’re storing but never querying, so the exhaust gets dropped at the edge instead of billed at the backend. Data efficiency becomes our engineering problem to solve, not your budget problem to absorb.
Honestly: the exact shape of cloud pricing isn’t settled yet, and there may need to be guardrails for genuinely extreme volumes. But the principle is settled. If we ever find ourselves designing a meter that makes us money when your telemetry grows, we’ll have become the thing we built Sluicio to replace.
The ledger test
Our simple test for monitoring costs: the tool should sit on the savings side of the ledger. It should cost less than the outages it prevents, the refunds it avoids, and the 2 a.m. hours it gives back. A pricing model that punishes you for sending data fails that test before the tool even gets a chance to pass it.
So that’s the model: free to self-host with no limits, one honest meter for the enterprise layer, and a public commitment to carry the same philosophy into the cloud. The current numbers are on the pricing page — marked as an early draft, because we’re still in private beta and reviewing them with real users. If you think we’ve gotten something wrong, that’s exactly the feedback we want: talk to us.