Metered and reported, not billed. Every usage line comes back with
unpriced: true today: the platform measures drain traffic and attributes it to your organization, and charges nothing for it. The line item exists so that the numbers behind any future price are visible before it exists, not after.What is metered
One record per settled batch, and one per drop — never one per record.
Billable is
deliveredRecords − rejectedRecords. Nothing else. Drops and failures appear on the row so you can see the gap and reconcile it against your delivery rows, and they are excluded from every billable total.
A retry is not metered. Those records are not settled; they re-enter the pending pool and are metered when they eventually settle. Metering a retry would count the same records twice.
A heartbeat, a verification, and an in-band drop report are the platform talking about itself, so none of them is metered either.
The billable figure is computed per batch and then summed — not as
Σdelivered − Σrejected. A terminally refused batch meters delivered: 0, rejected: N; on its own row that is zero, but subtracted from a total it would credit N against batches that were delivered successfully. One failed batch would quietly reduce what you are counted for on your successful ones.Bytes are pro-rated by each batch’s own accepted fraction, for the same reason: there is no per-record byte count to subtract, so pro-rating per batch keeps the error inside that batch instead of spreading it across the month.GET /admin/orgs/:orgId/usage/log-drains
Scope:usage:read — the same scope as the rest of the usage dashboard, and narrower than logs:manage. The response reports your own traffic and carries no drain configuration, no endpoint, and no credential.
string
YYYY-MM. Defaults to the current UTC month.usd is max(eventsUsd, bytesUsd) — never the sum. The per-event and per-GiB readings are alternative readings of the same traffic, and adding them would count one delivery twice.
No monetary figure is ever written onto a usage record. The line is priced at read time from the current price card, which is why correcting a card fixes last month’s report rather than only next month’s.
unpriced: true means the price card is all zeroes — metered, not yet priced.
Daily allowances
Each drain has a daily event and byte allowance from your tier:
Going over degrades the drain in steps rather than cutting it off:
warn and error records are the last to go: the ladder never drops them before it pauses the drain. Counters reset at 00:00 UTC.
A read of a drain reports your plan’s live limits, not the ones in force when the drain was created. An organization that upgrades this morning is told its new ceiling straight away, on the same
quota block, with its counters, resetsAt and degradation untouched. There is nothing to re-create and nothing to migrate.Reconciling against your own destination
The usage numbers and the delivery rows for the same batch carry the same counts, so the comparison is an equality rather than a tolerance. Delivery rows are kept for 7 days, so only a recent window can be compared this way.See also
- Delivery guarantees — the ladder, and what a drop looks like
- Drain notices — who is told at 80%, and at 150%
- Log drains REST — the drain routes and the
quotablock on a read lua drains—status --jsonand itsquotafield