Metering explained: how usage becomes credits

A spending limit is only trustworthy if the number it compares against is trustworthy. So here is the whole metering chain, including the parts that are imprecise and which direction the imprecision favours.

The chain

[1] scrape     every 15 s     kubelet, cAdvisor, Traefik, MinIO, CNPG
[2] rollup     every 60 s     15 s samples → 60 s grains
[3] price      every 60 s     grains → credits, display-unit formula
[4] book       every 60 s     → credit_ledger, atomic += on spend_caps
[5] reserve    on demand      before anything expensive starts

End to end, from a CPU second being consumed to it counting against your limit, is under two minutes.

What we measure, and how

CPU from the kubelet's cumulative counter, using increase() so a container restart does not read as a spike. Precision about ±1%. The first fifteen seconds after a pod starts are not counted, which favours you.

Memory from the allocated limit, not the working set. This is exact, because it is a configuration value rather than a measurement. You are billed for what was reserved for you, because we could not sell it to anyone else. The working set is graphed alongside it so you can see how much room you are wasting.

Storage from the volume's allocated capacity, sampled every five minutes and interpolated to the minute. Growth inside a five-minute window is only seen at the next sample — up to five minutes free, which favours you.

Object storage from the storage layer's own usage metric, with delete markers subtracted. Without that subtraction you would be billed for the tombstones of files you deleted, which would be indefensible.

Requests from the edge access log, one count per completed HTTP response. Requests blocked before they reach us never count.

Database instance hours from the cluster status. running and degraded count; paused and provisioning do not.

Build minutes from the builder, wall clock from start to finish. Queue time is excluded.

Which way the imprecision points

Every measurement has error. Ours points the same direction, on purpose:

This is not generosity. It is that a metering system whose errors favour the vendor is a metering system nobody should trust, and we would rather give up a fraction of a percent than have that argument.

Credits, and why they exist

One thousand credits is one euro, exactly, always.

The reason for the unit is readability. A vCPU minute costs 0.05 credits — € 0.00005. An invoice denominated in euros at that scale is a wall of leading zeros, and every usage table becomes an exercise in counting decimal places.

Every item is shown in both units on the pricing page, so nobody has to translate.

Rounding happens exactly once

This is the subtle part and it is where a naive implementation quietly overcharges.

Each metric has a display unit — a GB month, a vCPU minute, a million requests — and a price per display unit. The bookable cost is:

cost = max(quantity_in_display_units − included, 0) × price_per_display_unit

computed in high-precision decimals, and rounded to whole credits exactly once, when the line is written to the ledger, per metric per day.

The tempting alternative is to precompute a per-sample unit price and multiply. That is faster, and it is wrong: at nine decimal places the per-sample price for something like egress rounds up by about 2%, and multiplying by a large sample count turns a rounding artefact into a real amount — in our favour, which makes it exactly the kind of bug that never gets reported.

So the display-unit formula is normative for every monetary booking. The per-minute figure you see in the live graph is calculated the fast way and is explicitly indicative.

Reservations

Booking tells you what already happened. Reservations are what makes the limit hard.

Before an expensive operation starts — a build, a database, a scale-up — the platform reserves the credits it expects to need:

remaining = cap − used − reserved
if remaining < 0: refuse

in the same transaction that would otherwise permit it. The reservation is released when the operation finishes and the real cost is booked.

This is why the ceiling is a ceiling rather than an alarm: the check is in the path, not on a timer.

Idempotency

Metering runs continuously and things fail. Every guard against double counting is a database constraint rather than a convention:

• A unique constraint on the sample grain, so a repeated scrape cannot insert twice.
• An ingest batch identifier on every write.
• A unique constraint on (source_type, source_id, metric) in the ledger, so a rerun of the pricing job cannot book the same usage twice.

A rerun after an incident produces the same numbers. That is not a nice property; for a system that decides invoices, it is the only acceptable one.

Seeing it yourself

cmdz usage --breakdown metric --period current
cmdz usage --breakdown endpoint
cmdz usage --diff 41 42

The same data your invoice is built from, not a summary of it. Your agent reads the same thing through cmdz_get_usage and cmdz_explain_cost.