Your observability bill is decided before you ever see it

Metrics pricing is driven by cardinality — the number of distinct label combinations you send. One deploy that adds a user ID, a request path or a container ID to an existing metric can multiply that overnight. Nothing rejects the data, nothing pages anyone, and the number arrives weeks later on an invoice.

The asymmetry that makes this worth building. The large vendors bill cardinality as a line item. That means a customer’s mistake is the vendor’s revenue, and nothing upstream of the invoice has any reason to stop it. Tare caps it instead of charging for it — which is the one position a company funded by that line item cannot copy.

Where it sits

In front of whatever you already send telemetry to. It does not replace your backend, own your data, or ask you to migrate anything.

your services ──▶  Tare  ──▶  the backend you already pay for
                    │
                    ├─ budget enforced BEFORE anything leaves
                    ├─ runaway cardinality capped, by service, by name
                    └─ "what is this about to cost me?" answered up front

What it actually does

Refuses over-budget telemetry before the cost exists

A budget that is checked after the data has been forwarded is a report, not a control: the request gets recorded as blocked and the bill still arrives. Tare refuses at the hop before the vendor, so the spend never happens.

Verified by standing up a stand-in vendor that records every request it receives, then breaching the budget: the refusal was returned and nothing reached the vendor at all. A companion check confirms traffic resumes once the budget is lifted, so that result cannot come from a fixture that quietly died.

Caps the runaway service without silencing the rest

A tenant-wide block is self-defeating: it takes away the telemetry you need to diagnose the very thing that triggered it. Tare attributes the explosion to a single service and refuses that one, naming it and the limit it crossed.

Observed under enforcement: 80 distinct series measured and attributed to the offending service, the cap set to 40, that service refused with a code naming it — and a different service in the same workspace still accepted. That last half is the whole point; a tenant-wide cap would look identical without it.

Answers the cost question before the deploy, not after

Ask what adding a given number of new series would do to the month before you ship the change that adds them.

The same measurement drives enforcement, so the forecast and the thing that refuses cannot disagree with each other.

Says so when it cannot tell

A payload it cannot read reports unknown and the cap stands. A budget it has not been able to evaluate says exactly that, rather than showing a reassuring green.

This is the discipline the rest of this site is built on: not being able to check something is never recorded as having checked it and found nothing wrong.

How it has been checked

The interesting failures in this category are quiet ones — a cap that reports as configured and is inert, a budget that meters data the backend actually rejected. So the checking is aimed at those.

Every guard has been watched failing. Each rule is deliberately broken in turn and the run is only valid if its check goes red for the right reason — alongside a deliberate change that must not be caught, so “everything was caught” cannot be reported by a suite that is simply broken.
Verified against a running system, not only in tests. One early round was thrown out because it had been reading a container built four hours before the work it was supposed to be checking.
A cap that was configured, reported as configured, and completely inert. Cardinality was only measured while a second budget existed, so a workspace running one budget alone enforced forever against a snapshot that never refreshed. No unit test could see it; only running it for real did.
Data the backend rejected was being billed in full. The protocol has a success response that reports partial rejection inside the body. Reading only the status code meant the customer paid for records nothing stored.
Its own verification scripts were wrong more often than the product. Run as a set for the first time, five of fifteen failed — and four of the five were defects in the checks, each announcing a failure against a system that was working correctly.

Where it honestly stands

Tare is a working system, not a hosted service. There is nothing to sign up for on this page, and there are no customers on it. It runs as a single writer — a documented pilot boundary, not a hidden one — which is fine for one deployment and is the work that remains before it is fine for several.

The source is private, so unlike the free tools on this site you cannot go and read it. That is why this page leads with what has been measured rather than asking you to take the architecture on faith.

No prices are quoted here on purpose. The development configuration uses a placeholder rate, and quoting a number derived from it — or the incumbent’s published rates, which move — would be overclaiming by the quarter.

If your telemetry bill has ever surprised you

That surprise is the problem this is pointed at, and the interesting part of the conversation is usually which of your services would have been the one refused. Worth a short conversation either way.

Start a conversation See everything we have built →