Key Takeaways

• A metered event needs four things to be billable: a customer identifier, a timestamp, a quantity, and an idempotency key. Missing any one of them makes the event unusable at invoice time.

• Metering counts and pricing rates. Keeping the two separate is what lets a price change ship without replaying event history.

• The timestamp that matters is when usage happened, not when the event arrived, and the two diverge under retries and outages.

• Late-arriving events need a bounded acceptance window that's a stated policy, because an unbounded one means no period ever truly closes.

• Metering is not monitoring. Observability tolerates sampling and dropped points, and a billing meter can't.

What has to be true for an event to be billable?

Four properties, and an event missing any of them can't be turned into an invoice line afterwards. This is the contract between whatever emits usage and whatever bills for it, and most metering failures are really failures to enforce it at the edge.

The idempotency key is the one teams skip, and it's the one that produces the worst failure. A client that retries on timeout will send the same usage twice, and without a key the meter has no way to know. The customer gets billed twice for one action, notices, and now every number you produce is in question.

The timestamp deserves the same care. Record when the usage occurred, not when your ingestion endpoint received it, because a retry queue draining after an outage will otherwise stamp a day of backlogged usage onto a single minute.

How do you handle events that arrive after the period closes?

With a stated window and a decided policy, not case by case at month end. Some lateness is guaranteed: clients buffer, networks fail, mobile devices sync hours later, and a queue backs up.

The decisions worth making in advance:

1. How late is too late. Pick a window, 24 or 72 hours past period end being common, and reject beyond it rather than accepting silently.

2. Where a late event lands. Either it adjusts the period it belongs to, forcing a restatement, or it appears on the current invoice as a labeled adjustment line. Both are defensible. Undocumented is not.

3. Who gets told. Finance needs to know a closed period moved, because event ingestion reopening a closed month is a reconciliation event, not a silent correction.

An unbounded window sounds generous and is actually the worst option, because it means no period is ever final and every historical revenue number stays provisional.

What does keeping a meter accurate actually cost?

More than the ingestion endpoint, which is the part teams estimate correctly and the smallest part of the bill. The ongoing cost is reconciliation, replay, and the on-call burden of a pipeline that can't drop data.

The work that doesn't end after launch:

• Deduplication state, kept long enough to catch a retry that arrives well after the original.

• Reprocessing when a meter definition changes and historical events need recounting.

• A reconciliation path proving the meter total matches the source system, run every period rather than when someone complains.

• Cardinality management, since attributing usage across customer, feature, model, and region multiplies the series being tracked.

• An audit trail granular enough to walk one invoice line back to the individual events behind it.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Its metering path holds P99 under 60ms, the figure that decides whether a usage check can run inline in a request, and clears more than 20 billion events a month. TestZeus replaced manual usage tracking where every pricing change needed engineering, and had the integration live in three days with one engineer. The Usage Metering feature page covers ingestion sources and the event debugger that exposes every ingested event. The ingestion API reference is at docs.flexprice.io.

Related terms

Metering is the first stage of a chain, and these are the stages around it.

• Usage Event is the record the whole system is built to move.

• JSON Meter defines how raw events roll up into the quantity a rate multiplies.

• Idempotency Key is the field that makes retries safe to accept.

• Event Ingestion is the entry point where the four-property contract gets enforced.

• API Metering is the same discipline applied to request-level products.

• Ledger is what a meter total has to agree with at close.

FAQ

How does usage metering differ from usage aggregation?

Metering captures and stores individual events. Aggregation rolls those events into a single number per customer per meter per period. Metering is the record-keeping layer and aggregation is the arithmetic on top of it, which is why a change to how you aggregate can be replayed while a gap in metered events cannot.

Can you use your observability stack for billing?

Not safely. Metrics pipelines are built to be cheap at volume, which means sampling, downsampling old data, and dropping points under pressure. Every one of those is correct for a dashboard and unacceptable for an invoice. A billing meter needs exactly-once semantics and complete retention for the dispute window.

How real-time does metering need to be?

It depends on what reads it. Monthly invoicing tolerates minutes or hours of lag. Anything gating access in the request path, like a spending cap or a credit balance check, needs single-digit or low double-digit milliseconds, because that latency lands directly in your customers' API response times.

What happens if a metered event is lost?

You under-bill, and you usually never find out. Lost events are the quiet failure mode: the invoice looks plausible, the customer has no reason to complain, and the revenue simply never appears. That asymmetry against double-billing, which customers report immediately, is why reconciliation against a source of truth has to be a scheduled job.