Do I Pay for Queue Time on GitHub Actions Runners?

Answer

No, billing starts when the job runs on a machine, so waiting in the queue is a delivery problem rather than a line on the bill. GitHub bills Actions minutes for job execution, rounded up to the nearest minute per job, per the GitHub Actions billing documentation (checked on 2026-08-13), and WarpBuild bills runner minutes from the moment the machine starts the job at the rates on the pricing page.

The timestamps make the split checkable on any run you already have. Every job object in the workflow jobs REST API carries created_at, started_at, and completed_at. Subtract created_at from started_at and you have the queue wait. Subtract started_at from completed_at and you have the interval that turns into money.

That third row is the only place where a queue changes the bill at all: a workflow split into many short jobs pays the rounding on each one, so job count matters to the invoice while wait time does not.

Detail

What the queue timings report separates

WarpBuild keeps wait time and run time in different tables, which is what makes the answer above auditable rather than theoretical. Per the reports documentation:

• The Queue Timings section has one row per runner label and stack, with run count, queue time P75, and queue time P90, plus a daily bar chart of average queue time and job count.
• The Jobs section has one row per repository, workflow, and job name, with duration P75 and P90 next to queue time P75 and P90, so a job that got slower and a job that started later look different.
• The CI billing table has one row per job execution, carrying execution time, billed time, and the split between runner cost and snapshot cost. Queue wait appears in none of its columns.

Every one of those tables exports to CSV with the current filters applied, so the before and after comparison is a spreadsheet rather than a screenshot.

Why queue time still costs money

Queue minutes are unbilled, which is exactly why they survive for years. They are paid in engineer hours. Here is one team converted into numbers, with the assumptions stated so you can substitute your own from the Queue Timings report.

Assumptions:

• 30 engineers, each opening 4 pull requests per week that gate on a required check: 120 gated runs per week.
• Queue time P75 of 5 minutes on the busiest runner label, read off the Queue Timings table.
• Half of those runs (60) have a person actively waiting on the result before they can review, merge, or ship.
• A loaded engineer cost of $120 per hour.

The arithmetic:

• 120 runs x 5 minutes = 600 queue minutes per week across the team.
• The watched half: 60 runs x 5 minutes = 300 minutes, or 5 engineer hours per week.
• At $120 per hour that is $600 per week, or $31,200 across 52 weeks.
• Each minute shaved off P75 returns 1 engineer hour per week (60 runs x 1 minute), worth $120 per week or $6,240 per year.

Now the billed side of the same 120 runs, at rates from the cloud runners catalog and the pricing page, checked on 2026-08-13:

Assume each of the 120 runs holds warp-ubuntu-latest-x64-8x for 8 minutes of execution. That is 960 runner minutes, or $15.36 per week, the third row above at 120 runs.

So this team's invoice for those runs is $15.36 a week and its wait is $600 a week of engineer time. The number that never appears on a bill is the larger of the two by a wide margin, which is the practical reason to treat queue time as a budget item even though no one charges for it.

Where to see wait time per runner label

Open the Queue Timings report and sort by queue time P90, then filter to one runner label at a time. Two shapes show up. A label with a high P90 and a normal P75 is bursting past its capacity at specific hours. A label where P75 and P90 are both high has a steady shortage, or a runs-on value that no online runner advertises, in which case jobs sit forever with an empty log. The queue times guide works through the five causes and the fix that matches each one, and the queue time definition covers the term itself.

The daily series on that report splits total queue time into the GitHub side and the WarpBuild side of the handoff, which tells you whether to look at your account and runner group configuration or at capacity.

What the wait looks like after the pool goes away

Creates a fresh ephemeral machine for each job when that job queues, so a 16-way matrix gets 16 machines instead of waiting in waves for a fixed pool. Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. That covers generally available features on Linux and Windows runners; for high concurrency on macOS runners, contact [email protected]. Label strings are in the cloud runners catalog, and how fast runners start after a job is queued covers what replaces the wait.

What the bill actually contains

The full rate list is on the pricing page.

Related Questions

Does GitHub Actions bill the minutes a job spends queued?

No. GitHub bills job execution time, rounded up to the nearest minute per job (GitHub Actions billing documentation, checked on 2026-08-13), and WarpBuild bills runner minutes from the moment the machine starts the job. The wait before that lands in the Queue Timings report rather than on the invoice, and the CI billing row proves it by carrying execution time and billed time with no queue column.

Where do I see queue time per runner label?

The Queue Timings report groups every job by runner label and stack and reports run count, queue time P75, and queue time P90, alongside a daily average chart and CSV export. The Jobs report adds the same percentiles per repository, workflow, and job name. Both are documented in the reports documentation.

If queue time is free, why fix it?

Because it is paid in engineer hours instead of dollars. On the model above, 60 watched runs a week waiting 5 minutes each is 5 engineer hours a week, or $600 at a $120 loaded hourly cost, against $15.36 of billed runner minutes for the same runs at $0.016 per minute (rates checked on 2026-08-13 on the pricing page). Every minute removed from P75 returns about $6,240 a year on those assumptions.

Do WarpBuild runners have concurrency limits?

Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. That covers generally available features on Linux and Windows runners; for high concurrency on macOS runners, contact [email protected]. The queue times guide explains why account ceilings and fixed pools are the usual source of a long wait.