Metering model

Metering is the part of the platform that must never be wrong. A dropped event is unbilled work; a duplicated event is a customer overcharged. The pipeline is built around both failure modes.

The pipeline

Meters

Time

Time accrues only in running. provisioning is free — a cold start is the platform's failure to have a warm instance, and billing for it would pay the platform for being slow.

Compute

CPU is actual and memory is allocated, deliberately. CPU can be shared, so charging for use is fair. Memory cannot be meaningfully overcommitted, so the allocation is what is consumed from the fleet whether or not the guest touches it.

Network

Storage

Storage meters are emitted hourly and prorated, so a volume that exists for six hours bills six hours of a GiB-month, not a whole month.

Activity

browser_page_s is the meter teams overlook. Ten open tabs for sixty seconds is six hundred page-seconds, not sixty.

Reserved capacity

Only appears for organizations that bought a latency guarantee. The capacity is genuinely held for them, so it is genuinely billed.

Event shape

{
  "session_id": "sess_2kQ9xwR4",
  "meter": "tier2.session_s",
  "window_start": "2026-10-06T09:21:00Z",
  "window_s": 60,
  "quantity": 60,
  "organization_id": "org_2kQ9xw",
  "project_id": "proj_7fTn21",
  "end_user_id": "eu_customer_4821",
  "region": "bom1",
  "tier": 2,
  "source": "node",
  "node_id": "node-bom1b-0412"
}

Dedupe key: (session_id, meter, window_start). A retried event with the same key is discarded at ingest, which is what makes at-least-once delivery safe.

Correctness

No lost usage

Nodes write every sample to a local write-ahead log before acknowledging it internally, stream from the WAL, and truncate only on acknowledgement. A node that cannot reach metering keeps running sessions and keeps buffering for up to 24 hours. Past that it raises a critical alert and refuses new placements, because beyond that point the platform is doing unbilled work.

No double billing

The dedupe key makes redelivery a no-op. Redeliveries are expected and counted — events_deduped is a normal non-zero metric, and a spike in it means node retries, which is a transport problem rather than a billing one.

Nightly reconciliation

A job replays a sample of completed sessions from archived node WALs and compares the result against billed usage. Any mismatch is a billing incident, handled at the same severity as an outage. This is the check that catches a class of bug no amount of unit testing does: a pipeline that is internally consistent and wrong.

Reproducible rating

Rated usage stores price_list_id and price_list_version. Re-running the rating for a past period produces the same numbers, which is what makes an invoice explainable a year later.

Freshness

usage_to_date on a live session object bypasses the pipeline and comes from the node's last flush, so it is fresher — under 15 seconds — but it is an estimate. The billed figure is whatever the pipeline settles on.

Attribution

Every event carries organization_id, project_id and, when set, end_user_id. All three are captured at emission.

end_user_id cannot be backfilled. An event emitted without it is permanently unattributed. This is not a limitation that could be engineered away — the association exists only in the caller's head at the moment of the request. Set it on every create from day one. See end-user billing.

What is not metered

• Provisioning and teardown time. Platform cost, not customer cost.
• Failed starts. A session that never reaches running bills nothing.
• Control-plane API requests, below a generous threshold.
• Pool capacity, unless the customer bought a reservation.
• Template builds and storage, below a per-project threshold.
• Webhook deliveries, logs, traces and the audit log, within retention.

The principle: customers pay for compute they used and storage they hold. Everything the platform does to make that fast and safe is the platform's cost of doing business.