Meter every event.
Tokens, API calls, compute seconds, seats — one ingestion pipe, aggregated in real time. Every unit your product emits becomes a billable line — and a real-time entitlement check — the moment it happens.
Updated August 2026Correctness at scale, not just at demo speed.
Three steps. No engineering ticket.
One API call or SDK line per usage moment — tokens, API calls, compute seconds, seats. No schema to pre-register.
The append-only ledger deduplicates retries by idempotency key and aggregates in real time, per customer.
The new total feeds pricing, entitlements and the dashboard the same second — no batch job, no delay.
From event to invoice line, in one pipe.
A usage event is a single record — a token count, an API call, a compute-second, a seat — sent to Kribana the moment it happens, tagged with an idempotency key. That key is what makes the ledger safe under retry: if your infrastructure sends the same event twice because a network call timed out and got retried, the second delivery is recognized and dropped, not billed twice. You don't have to build de-duplication logic on your end; it's the default behavior of the ledger itself.
Every event lands in an append-only ledger — nothing is ever mutated or overwritten. Totals, invoices and entitlement checks are all derived views computed from that ledger, not counters that drift out of sync with reality. That's also what makes correction painless: if an event needs adjusting, a new event is appended rather than an old one edited, so the full history of what happened stays intact and auditable.
Events don't always arrive in order, and they don't always arrive on time. A batch job might report its token usage twenty minutes after the request finished; a mobile client might sync usage after being offline overnight. Kribana folds events arriving up to 72 hours late into the correct billing period automatically — no manual correction, no re-issued invoice, no support ticket. Aggregation was built assuming events would be late and out of order, not as an edge case bolted on afterward.
The same ledger that bills also answers "can this customer do this right now?" — entitlement checks read from the identical source of truth as invoicing, so there's never a gap between what a customer has paid for and what they're able to use. And because test API keys write to a fully sandboxed ledger, you can validate a new event type or pricing model against realistic volume before a single live event or dollar is involved.
This matters most for AI companies billing on tokens and credits, where a single request can emit thousands of meterable units and a wallet can burn down in minutes rather than weeks — the ledger has to keep up in real time, not on a nightly batch.
“Finance stopped asking if the usage numbers were right. That's the real win.”
FAQ
What happens if the same usage event is sent twice?
Nothing gets billed twice. Every event carries an idempotency key, and the ledger checks incoming events against it before aggregating — a retried delivery from a timeout or a network blip is recognized as a duplicate and silently dropped rather than counted again. You don't need to build your own de-duplication layer before sending events to Kribana; it's the ledger's default behavior, not an opt-in setting.
How late can a usage event arrive and still bill correctly?
Up to 72 hours. Events don't have to arrive in order or on time to land in the right place — a batch job reporting usage after it finishes, or a client syncing after being offline, still gets folded into the correct billing period automatically. There's no manual correction step and no re-issued invoice required on your end when this happens.
Can I meter more than one unit type — like tokens and seats — on the same account?
Yes. Metering isn't limited to a single unit per account — tokens, API calls, compute-seconds and seats can all feed the same ledger and combine into one pricing model, including hybrid seat-plus-usage plans. Each event type is tagged separately, so the pricing engine can apply different rates or tiers per unit within a single invoice.
Does metering add latency to my product's requests?
No — sending a usage event is a fire-and-forget API call or SDK line that doesn't sit in your product's critical path. Entitlement checks (whether a customer is allowed to do something right now) are a separate, fast read path built for the hot path, including an edge SDK with local caching for zero added latency, so metering and access enforcement never slow down the request itself.
How do I test metering before going live?
Test API keys write to a fully sandboxed ledger that's completely separate from live billing data. You can send realistic event volume, validate a new event type or pricing model, and confirm aggregation and invoicing behave as expected — all without a single test event or dollar touching a real customer's account.