Usage
How to read the usage view in the console, what each figure means, and when a number stops moving.
The usage view shows what your organization consumed during a billing period, per metric and per application, priced with the same rules the invoice uses. Open it when a charge, a projection or a near-limit warning needs explaining.
What the page shows
The period picker covers the last six billing periods, including the one in progress. The view then narrows from the whole cycle to items that need attention, spend, individual metrics, and the applications behind them.
| Section | What it answers |
|---|---|
| Billing cycle summary | Where the cycle stands, what it is projected to reach, how it compares to the previous cycle |
| Needs attention | Which metrics are at or trending past their allotment before the cycle ends |
| Spend overview | Daily or cumulative accrual beyond allotments, split by category |
| Metrics by category | Every metric grouped into Requests and Delivery, Functions, Storage and Platform |
| By application | Usage and attributed spend per application |
Reading one metric
Each metric carries four figures.
- Cycle to date is the metered quantity so far this period.
- Previous is the same measure over the equivalent elapsed window of the previous period, so a comparison drawn on the 9th is against the previous month's first nine days.
- Projected extrapolates cycle to date across the whole period at the rate so far. It equals the total once the period closes.
- Spend is the amount the invoice will carry for that metric.
Alongside those sits a status. A metric reads as "Near limit" from 80% of its allotment and "Over limit" from 100%, and both feed the attention panel. A metric with no allotment, billed from its first unit, reads as "Metered" instead. Usage metrics lists what every metric measures, its key, and the unit it is stored in.
When a figure stops moving
Raw events are summed into hourly buckets, and every figure on the page is read from those buckets rather than from the events. That is the hour of lag the console warns about. Each bucket then settles in two steps.
| When | What it means |
|---|---|
| 3 hours after the hour it covers | Past the ingestion grace window. In practice it stops moving here |
| 36 hours after the hour it covers | Frozen. This is what the invoice is built from |
The three hour grace exists because CDN delivery logs arrive one to two hours behind the traffic they describe, so a figure for the last hour or two is a lower bound rather than a final answer.
Why spend appears late in the cycle
Usage inside your plan allotment is not billed, and allotments are pooled across the organization rather than divided between applications. Spend starts accruing the moment cumulative usage passes the allotment, and not before.
A day on the spend chart is an increment, not a total
Each day's bar is the increase in the cumulative charge across that day, not that day's usage priced on its own. Early days read as zero even though usage happened, and one day can carry the charge for the days around it.
On a plan that does not bill usage overage the page still shows quantities and allotments, with a cost of zero, matching what the invoice will say. Plans covers which plans those are.
Spend per application
The per-application table splits usage exactly and spend approximately. Because allotments are pooled organization wide, there is no per-application bill to compute: each application receives a share of the organization's billable overage proportional to its share of the usage that caused it. Read those amounts as an attribution of one bill rather than as several bills.
Getting the numbers out
Usage is not exposed through the API or the CLI. Export CSV writes one row per metric per day for the selected period, with values in each metric's stored base unit rather than the unit the page displays. That is what lets an export reconcile line by line against Invoices without inverting a conversion first.