Usage & Metering
If you sell meters — API calls, gigabytes ingested, deliveries, seat-minutes — the Usage Control Center is where you watch them. It shows every metered subscription line, how much has been consumed against included units, what will be billed, and what the usage is worth in revenue.
Open it at Billing → Usage.
When should I read this?
- You bill per use and want to catch runaway customers before the invoice does.
- A customer is about to exceed their included units and you need to decide: upsell, overage, or a conversation.
- An invoice looks too high and you need to trace which usage events produced it.
Use cases
| Scenario | What you do |
|---|---|
| Month-end check before the bill run | Filter by Over included and Nearing included, then talk to those customers early. |
| A customer disputes their API usage | Open their meter row, drill into usage records for the billing window, reconcile event counts. |
| You want the revenue side of usage | Read the Estimated usage revenue card — it prices current usage at the product's tiers. |
The dashboard
Four cards summarize the fleet: Metered items, Total usage, Billable usage, and Estimated usage revenue.
Each row in the table is one metered subscription item:
| Column | What it tells you |
|---|---|
| Meter | Subscription, customer, and product. |
| Status | Guardrail state badge plus the subscription status. |
| Usage | Total consumed, included units, and a progress bar (red = over, amber = near, blue = within). |
| Billable | Quantity that will actually be billed, with the pricing mode and source. |
| Estimate | Money: estimated amount with the effective unit price. |
| Last usage | When the most recent event arrived and how many events exist. |
Guardrail states
| State | Meaning |
|---|---|
| Within included | Usage is inside the free/committed allowance. |
| Nearing included | Approaching the included limit — time for a heads-up call. |
| Over included | Beyond the allowance; overage will bill at tier rates. |
| Pay as you go | Pure metered product with no included units. |
Filter chips let you jump straight to any state, and the date range (From/To) scopes everything to a window. With no dates set, each subscription is evaluated over its current billing period — usually what you want.
How usage gets into Floatless
Three doors, one ledger:
- API ingestion — the normal production path. Post usage events to the usage events API; every event needs an idempotency key so retries can never double-bill. Only metered subscription items accept events.
- Manual report — on a subscription's Usage tab, Report Usage records a one-off correction with a note.
- Backfill/import — via the API in batches; keep the idempotency keys stable per source record.
Rating and the invoice
Usage is priced by the product's tier scheme (graduated or volume). The bill run pulls the usage accumulated in each subscription period, rates it against the locked tier table, and writes the result as invoice lines with the usage detail attached. That's why the estimate you see here matches — line for line — what the invoice shows later.
Common issues
- Usage is missing. Check the event's timestamp is inside the subscription's current period and that the idempotency key wasn't a duplicate (duplicates are dropped, not merged).
- A customer says they used less. Compare their records with the usage records for the period — the row's event count is the starting point.
- Estimate looks different from last month. Estimates follow the locked tier table of the subscription; catalog tier changes affect new subscriptions only.