How Do I See Cost per Runner Label?

Cost per runner label lives in the CI tab of the Billing report, where the daily chart groups spend by runner label and every table row is one job execution stamped with the label it ran on. Filter that table by label, read the cost total against the billed minutes total, and an oversized label doing small work shows up as a high rate paid for many minutes.

Answer

The CI tab of the Billing report carries three surfaces, and each one answers a different part of the question. The daily stacked bar chart plots cost per day grouped by repository or by runner label. The summary cards give total cost, runner cost, snapshot cost, and total jobs for the selected period. The table underneath writes one row per job execution, and the filters cover repository, runner label, stack, job name, and snapshot usage. Every tab exports CSV containing all rows matching the current filters and sort order rather than the visible page (reports documentation).

Here is what each field in a row does for a per-label question.

Reading minutes against the rate is one division. Filter the table to a single label, sum the cost column and the billed time column, and divide. The result should match the published per-minute rate for that label. Current Linux x64 rates from the pricing page are as follows.

An effective rate above the published one means snapshot cost is inside the row, which the cost split column separates. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so cost per label reduces to billed minutes multiplied by that label's rate and nothing else.

Detail

Put the label cost next to the utilization for the same job

Cost per label tells you where the money went. It does not say whether the machine was busy, so pair it with the Jobs section of the same report, which aggregates per repository, workflow, and job name and reports run count, success rate, duration P75 and P90, queue time P75 and P90, CPU P75 and P90, and memory P75 and P90. CPU and memory columns need Observability enabled; jobs without telemetry show a dash.

The threshold that separates a busy label from an oversized one is fixed. The Recommendations view marks an instance as under-provisioned at max sustained CPU, max memory utilization, or max filesystem utilization of 80 percent or higher, or max disk I/O at 80 percent of supported throughput. A job holding CPU in the low tens for a month of runs sits at the other end of that scale.

A worked example: a 16x label using two cores

Take a unit-tests job in one repository, running on warp-ubuntu-latest-x64-16x. The billing filter for that label over a month returns 1,000 job executions and 6,000 billed minutes. The Jobs row for the same job shows CPU P90 at 13 percent and memory P90 at 19 percent.

Two cores of a sixteen core machine is the signature the question was looking for. For reference on the same shape, warp-ubuntu-latest-x64-16x costs $0.032 per minute against $0.042 per minute for the 16-core Linux larger runner at 16 vCPU and 64 GB: 24 percent lower list price (GitHub pricing, checked 2026-08-13). Those same 6,000 minutes would bill $252.00 there. On a label this oversized, the size change moves more money than the rate difference does.

Move the label down and check the next month

Memory sets the floor here. The 12.2 GB peak rules out warp-ubuntu-latest-x64-2x at 8 GB, so the stop is warp-ubuntu-latest-x64-4x at 4 vCPU and 16 GB, which still leaves two idle cores against the measured peak.

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/test.sh

At the same 6,000 billed minutes, $0.008 per minute bills $48.00 against $192.00, a difference of $144.00 a month. Assume the job stretches 20 percent to 7,200 minutes on fewer cores: $57.60, still $134.40 below the starting point. Re-run the same filter after a week and confirm both numbers, the label total and the CPU P90, before touching the next label. The right-sizing guide covers the ladder in full, and detecting an undersized runner covers the move in the other direction.

What the label view does not cover

Queue time is tracked separately, in the Queue Timings section, per runner label and stack with run count and queue time P75 and P90. A label can be correctly sized and still cost engineering time waiting.

Docker Builder and Cache spend sit in their own tabs, per session and per cache entry, so a label total is runner and snapshot cost only. For splitting any of these across teams rather than across labels, cost attribution covers the label and job name conventions that make the CSV export a chargeback ledger.

Signup includes $10 free credits, which is enough to run a real workflow on two labels and compare the rows before the first invoice.

Related Questions

Where does cost per runner label live in WarpBuild?

In the CI tab of the Billing report. The daily stacked bar chart groups cost by repository or by runner label, and the table below it writes one row per job execution carrying repository, job name, runner label, stack, snapshot usage, execution time, billed time, and the cost split between runner and snapshot. Filter by runner label to get that label's total for the period, then export the filtered view as CSV (reports documentation).

How do I turn cost per label into a per-minute rate I can check?

Divide the filtered cost total by the billed minutes total. The result should match the catalog rate for that label, for example $0.032 per minute for warp-ubuntu-latest-x64-16x on the pricing page. A higher effective rate means snapshot cost is riding in the row, which the report splits into its own column.

What tells me a label is oversized rather than busy?

The utilization for the same job. The Jobs report shows CPU P75 and P90 and memory P75 and P90 per repository, workflow, and job name, and the Recommendations view flags an instance as under-provisioned only at 80 percent or higher. CPU in the low tens across a month of runs is the oversized signature, and detecting an undersized runner reads the same table for the opposite case.

What does moving a label down a size save?

Each Linux x64 step halves the rate. Dropping a job from warp-ubuntu-latest-x64-16x at $0.032 per minute to warp-ubuntu-latest-x64-4x at $0.008 per minute takes 6,000 monthly billed minutes from $192.00 to $48.00 at the same duration. The full rate list is on the pricing page, and the right-sizing guide works through the sizes where the trade turns.