Is There a Minimum Billing Increment?

The billing increment for a WarpBuild GitHub Actions runner is one minute. There is no five-minute block, no ten-minute block, and no per-job runner fee on top of the minutes, so a job's runner line is its billed minutes multiplied by the per-minute rate of the label it ran on.

Answer

Runners bill on a per-minute basis, which the WarpBuild pricing page states in its billing FAQ and the cloud runners documentation carries as a per-minute rate against every label in the catalog, both checked on 2026-08-13. One minute is the entire increment. A job that finishes in 40 seconds and a job that finishes in 60 seconds land in the same one-minute bucket, so a fleet with thousands of tiny jobs needs to watch job count as closely as total minutes.

That makes the minimum runner charge for any single job easy to read off the rate list: it is one minute at the label rate.

Rates come from the pricing page and the cloud runners documentation, checked on 2026-08-13. The floor for one job across the whole catalog is $0.003, one minute on warp-ubuntu-latest-arm64-2x, and the highest single-minute charge is $0.16 on warp-macos-latest-arm64-12x. Those four ladders are the complete picture.

The rate the increment multiplies is the other half of the answer. warp-ubuntu-latest-x64-2x (2 vCPU, 8 GB) costs $0.004 per minute against $0.006 per minute for GitHub-hosted ubuntu-latest on private repositories (2 vCPU, 8 GB): 33 percent lower list price. GitHub list price checked on 2026-08-13 at docs.github.com, where GitHub also documents its own per-minute accounting for GitHub Actions billing.

Billed minutes are not an estimate you have to reconstruct. The reports documentation describes a Billing section whose CI tab lists execution time and billed time in adjacent columns for every job execution, which is where the increment becomes visible per job.

Detail

Many short jobs against fewer long ones

The increment costs money only when jobs carry a fractional-minute tail, and the penalty scales with job count rather than with total work. Take 60 minutes of execution on warp-ubuntu-latest-x64-4x at $0.008 per minute and split it four ways.

At 400 pull request runs a month, the 90-job shape costs $288.00 and the 6-job shape costs $192.00 for identical work, a $96.00 monthly difference created entirely by job count. The bound is simple enough to budget against: billed minutes never exceed execution minutes plus one minute per job. A 200-job fan-out therefore adds at most 200 billed minutes, which is $1.60 on warp-ubuntu-latest-x64-4x and $0.60 on warp-ubuntu-latest-arm64-2x. The same worst case on warp-macos-latest-arm64-6x at $0.08 per minute is $16.00 per run, which is why short macOS jobs are the ones worth folding together first.

A sharded matrix is the usual source of forty-second jobs.

name: tests
on:
  pull_request:
    branches: [main]

jobs:
  unit:
    runs-on: warp-ubuntu-latest-x64-4x
    strategy:
      matrix:
        shard: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx jest --shard=${{ matrix.shard }}/10

Each shard pays for checkout and npm ci before it runs a single test, so the real cost of splitting is the rounding plus that repeated setup. Sharding still wins when developers are waiting on the result, since 10 shards return an answer in a tenth of the wall-clock time. It loses on a nightly schedule, where nobody is watching and the extra billed minutes buy nothing. The cost attribution guide covers how to find the matrices that grew past their usefulness.

Where billed minutes appear

The reports documentation, checked on 2026-08-13, describes three surfaces that carry the number.

Per job: the Billing section's CI tab gives one row per job execution with repository, job name, runner label, stack, snapshot usage, execution time, billed time, and the cost split between runner and snapshot. Sorting by the gap between execution time and billed time brings the rounded-up jobs to the top.

Per label and per repository: the same tab draws a daily stacked bar chart that groups by repository or by runner label, and filters cover repository, runner label, stack, job name, and snapshot usage. Summary cards total the period's cost, runner cost, snapshot cost, and job count. Every tab exports to CSV with all rows matching the current filters, which is the practical path into a spreadsheet.

Per job shape over time: the Jobs section aggregates each unique repository, workflow, and job name combination with run count, success rate, and P75 and P90 figures for duration, queue time, CPU, and memory. CPU and memory columns need observability enabled on the runner. Those percentiles are how a team decides whether a shard is short because the work is small or short because it is oversized.

The meters that do not use the minute increment

Runner minutes are one line among several, and the other meters carry their own units.

Rates from the pricing page, checked on 2026-08-13. A Docker builder session is measured from when the builder action starts until the job completes, and concurrent jobs sharing a profile share one session, so builder minutes and runner minutes are counted separately even inside the same job.

What the increment sits on top of

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so the per-minute increment is the only unit that turns work into a runner bill. Signup includes $10 free credits, which is enough to run a few thousand short Linux jobs while you measure how your own matrices round, and the full rate structure is on the pricing page.

To turn all of this into a forecast, multiply expected job minutes per platform by the rate for the labels those jobs use, then add one minute per job as the rounding allowance. The bill estimation answer works through that calculation on a monthly fleet, and the full rate list stays on the pricing page.

Related Questions

Is there a minimum charge for a single GitHub Actions job?

One minute at the rate of the label the job ran on. That is $0.003 on warp-ubuntu-latest-arm64-2x and $0.16 on warp-macos-latest-arm64-12x. No per-job runner fee is added on top of that minute, and the full ladder is on the pricing page.

Does a 20 second job cost the same as a 60 second job?

Yes. Both land in the same one-minute bucket, so a matrix of 90 forty-second shards bills 90 minutes while the same 60 minutes of work folded into 6 jobs bills 60 minutes. The reports view shows execution time and billed time side by side per job, which is the direct way to confirm it.

Do Docker builders, cache, and snapshots use the same one-minute increment?

No. Docker builders bill per session measured in minutes from $0.06 per minute, cache storage bills $0.20 per GB-month, cache operations bill $0.0001 each, snapshot restores bill $0.04 per job, and snapshot storage bills $0.025 per snapshot-hour. The cost attribution guide covers splitting those meters across teams.