Usage

The Usage page answers the question the Subscription page can’t: not just how many credits you have left, but what’s spending them. Every credit is spent by a workflow run processing documents, or by a handful of non-run actions like document ingestion and schema generation (see Credits for the per-node costs); this page shows how that total splits across your workflows, individual nodes, node types, environments, and sources. Open Settings → Usage, or click through from the Subscription page.

​

Burn-down

At the top of the page, a burn-down card compares credits used against your plan’s allowance for the current billing period. It shows:

• Credits used so far against your plan’s allowance, and what percentage that is
• Days left in the period
• A projected end-of-period total, calculated by extending your current pace in a straight line to the end of the period
• Whether you’re on pace to stay within your allowance or headed over it

The projection only appears once enough of the billing period has gone by for a straight-line extrapolation to mean something. Very early in a period, a couple of days of usage isn’t enough to project from, and a line drawn through it could swing wildly and alarm you over nothing. Once there’s enough of the period behind you, the projection appears and updates daily. Use this to catch an overspend early, while there’s still time to act, instead of finding out when the balance runs out.

​

Choosing a period

A period control above the chart governs both the chart and the breakdown table below it, so they always describe the same range. It defaults to your current billing period, the same period the burn-down card above shows. The burn-down card doesn’t change with anything you pick here, and says so under its numbers whenever you’re looking at a different range. Choose a preset (This month, Last month, Last 3 months) or set a custom date range, then click Current period to jump back to your billing period.

​

Daily usage chart

Below the burn-down, a stacked bar chart shows credits consumed per day across the selected period. A group-by switcher lets you split each day’s bar by:

• Workflow
• Node (a single node in a single workflow, by its name in the builder)
• Node type
• Environment
• Source (workflow runs versus document ingestion, schema inference, and other non-run spend)

Spend with no run behind it still appears in every one of these views, named for what caused it: a Document ingestion row and a Schema inference row sit alongside your workflows rather than being pooled into a single anonymous entry. They have no run to open, so they don’t expand. Under Workflow, a document that arrived through a workflow’s trigger is attributed to that workflow. A document that arrived at an inbox is listed under the source name, and stays there after a rule or a person assigns it: the credit was spent on arrival, before it had a workflow. Node is the most specific view. Two extract nodes in the same workflow get their own rows, so “which step is expensive” is a question you can answer directly rather than by inference. Each row names its workflow alongside the node, because the same node name is common across workflows and identical after a copy. If you rename a node, its history follows the new name. Switching the group-by re-slices the same totals along a different dimension, so you can go from “which day spiked” to “what caused it” without leaving the page.

​

Breakdown table

Underneath the chart, a ranked table lists every group for the selected dimension and period, each row showing its environment, credits, share of the total, billed steps, page count, and credits per page. Anything past the top entries folds into a single Other row rather than disappearing, so the table always accounts for the full total. Environment names the one environment a row’s credits were spent in. It matters most after you promote a workflow: the copy keeps its name, so a workflow you promoted to Production shows up as two rows reading the same thing, and the environment is what tells them apart. A row that isn’t about a single environment leaves the column empty, which is any Node type or Source row that ran in both, and the Other row. Grouped by Environment the column disappears, since it would repeat the group name on every line. In the chart, where there are no columns, the environment is appended to the name instead (Test · Production), but only when grouping by Workflow or Node. Those are the two views where a row is a specific thing in a specific environment. A node type or a source is whatever ran, wherever it ran, so its environment stays in the table. Billed steps counts step executions that were charged. It is a count of executions, not of nodes: a loop body that ran 50 times counts 50, which is usually the fastest explanation for a row that looks more expensive than the workflow it sits in. Grouped by Workflow or Node type, click a row to expand it into the individual runs that contributed to that group. Grouped by Node, Environment, or Source, rows show totals only and don’t expand. For environment and source that’s because they’re broad slices across many workflows rather than a single set of runs. For a node it’s the opposite problem: listing the runs of its workflow would include runs that never reached that node, which would be worse than showing nothing.

​

Drilling into runs

Expanding a breakdown row (available when grouped by Workflow or Node type) lists the runs behind those credits as a paged list, showing each run’s credits, billed steps, page count, date, and environment. Click a run to open its run detail page.

​

Exporting to CSV

Click Export CSV in the expanded runs list to download those runs as a CSV file, useful for sharing a cost breakdown with a teammate or reconciling against an invoice offline.

​

What a number on this page means

Every row is the actual charge for the work it names. Nothing on this page is an estimate, a share, or an apportionment. This follows from how a run is billed: a run costs the sum of the steps it ran, so each step’s own charge is its own number, and those numbers add up to the bill with nothing left over. Add every row in the table together and you get exactly what those runs cost. Price a node yourself from the Credits page, multiply by the pages it processed and the times it ran, and you get its row. There is no “unattributed” row, because there is nothing left to attribute. Two things still surprise people, and neither is a rounding artifact:

• A node inside a loop shows the whole loop’s spend. Its billed steps count tells you how many iterations that was. One extract at 2 credits per page over a 3-page document, run 50 times, is 300 credits on one row.
• A run of the same document twice costs the same both times. Ingestly caches extraction results, so the second run is faster, but the cache saves processing rather than money and the step bills its normal rate.

If a row looks higher than you expected, the answer is almost always in its billed-steps count or its page count, both of which are on the same row.

​

When usage detail starts

Usage detail collection began when this page shipped. Look back far enough with the period control, for example a custom range or the Last month preset if you’re checking soon after this feature launched, and you’ll reach a period that falls entirely before that date. For those periods, the breakdown table and daily chart show an empty state instead of partial or misleading numbers. A period that overlaps the start date still shows data, just only from that date onward. Your credit balance and transaction history are unaffected: only the per-workflow, per-node breakdown has no data for periods before then.

​

Related