Skip to content
Sengi

GitHub Actions billing explained: how a minute is counted and what else spends it

How does GitHub Actions billing work?

GitHub Actions bills the execution time of each job, rounded up to the whole minute, at its runner's published rate, which is $0.006 for a standard Linux 2-core minute as read on September 13, 2026. Queue time is free, every matrix entry is billed as its own rounded job, and failed and cancelled jobs bill the minutes they ran. Storage is a separate meter at $0.25 per GB-month. Larger runners never draw on included minutes.

Last checked September 13, 2026: every rule and rate on this page was read from GitHub's own published billing documentation, runner pricing reference and changelog on that date, and is quoted here so you do not have to go and find it.

What counts as a GitHub Actions minute?

Execution time, rounded up once per job. GitHub's runner pricing reference, read September 13, 2026, states that GitHub “rounds the minutes and partial minutes each job uses up to the nearest whole minute.” That sentence carries most of the surprise in an Actions bill: the rounding is per job, not per workflow and not per run, so a workflow of ten jobs that each take 30 seconds bills ten minutes rather than five.

The rest of the meter is the part people assume and should not. GitHub's Actions billing documentation, read the same day, says “minutes usage is charged to the repository owner, not the person who triggered the workflow runs,” so a fork's contributor cannot spend their own quota on your repository, and a bot that opens pull requests spends yours.

EventBilled?Rule, read September 13, 2026
A job running on a hosted runnerYesExecution time, rounded up to the whole minute, per job
A job waiting in the queue for a runnerNoOnly the time workflows are executed on the runner is billed
Each matrix combinationYes, separatelyEvery combination is its own job with its own rounding
A job that failed partwayYes, for what it ranA 10-minute workflow failing after 5 minutes uses 5 minutes
A re-run after a fixYes, in fullThe failed 5 plus a successful 10 is 15 minutes in total
A cancelled jobYes, for what it ranBilled for the minutes before the cancellation, rounded up
A job on a standard runner in a public repositoryNoStandard GitHub-hosted runner use is free in public repositories
A job on a self-hosted runnerNoSelf-hosted runner usage is free; the machines are yours to pay for
A GitHub Pages build or a Dependabot jobNoStandard-runner use is free for GitHub Pages and for Dependabot
Artifact, cache and log storageYes, on another meterCharged in GB-months, not in minutes

One number makes the table concrete. At $0.006 a standard Linux 2-core minute, read September 13, 2026, a workflow of ten 30-second jobs costs $0.06 a run rather than $0.03, and on 400 runs a month that is $24.00 rather than $12.00 for exactly the same work.

How are matrix jobs, retries and cancelled runs billed?

Each matrix combination is a separate job with its own rounding, so a ten-minute build across six matrix entries bills 60 minutes, which is $0.36 at the $0.006 standard Linux 2-core rate read September 13, 2026. The wall-clock time is still ten minutes, which is why a matrix is the commonest reason a bill is larger than anyone's memory of waiting for it.

Failures bill what they ran. GitHub's Actions billing documentation gives the arithmetic itself, read September 13, 2026: “if you run a workflow that normally takes 10 minutes and it fails after 5 minutes because a dependency isn't available, you'll use 5 minutes of the repository owner's allowance. If you fix the problem and re-run the workflow successfully, in total you'll use 15 minutes.” A cancelled job is billed the same way, for the minutes it had already run.

Two consequences follow, and both are about volume rather than rate. A flaky job that is retried twice bills three times. And a push that supersedes an earlier push does not stop the earlier run: it keeps running, and it keeps billing, unless a concurrency group cancels it. Cancelling that stale run does not make it free, but it stops the meter where it stands.

Is GitHub Actions storage billed separately from minutes?

Yes. Storage is its own meter, charged in GB-months, and no included minute pays for any of it. The rates below were read from GitHub's Actions billing documentation on September 13, 2026.

MeterRateAllowance and notes
Artifacts and GitHub Packages$0.25 per GB-monthOne shared allowance: 500 MB on Free, 1 GB on Pro, 2 GB on Team, 50 GB on Enterprise Cloud
Actions cache$0.07 per GB-month10 GB per repository on every plan
Custom images$0.07 per GB-monthBilled on the same GB-month basis as the cache
Workflow logs and job summariesNo chargeThey “do not count towards the repository owner's artifact storage allowance”

Storage accrues by the hour and is converted at the end of the cycle. GitHub's worked conversion, read September 13, 2026, is “6,768 GB-Hours / (744 hours per month) = 9.0967 GB-Months,” which at $0.25 is $2.27 for that month. Two properties of that meter catch teams out. Deleting an artifact only stops future accrual: “deleting artifacts frees up space for current storage, but does not reduce your accrued storage usage.” And the figure you are looking at is stale by design, because GitHub “updates your artifact storage usage within 6 to 12 hours.”

The practical consequence is that an artifact retention policy pays back slowly and a cache that grows unbounded costs a little every hour rather than a lot on one day. Neither shows up in a minutes report, which is why a bill can rise while minutes stay flat.

Which other GitHub features spend my Actions minutes?

Four, as of September 13, 2026: Copilot code review on private repositories, GitHub Code Quality scans, automatic dependency submission, and code scanning workflows. All four run as Actions workflows on standard hosted runners, and all four draw on the same included-minute quota your CI does, which means a team can lose headroom without editing a workflow file.

FeatureDraws on Actions minutes?Since, and what else it meters
Copilot code reviewYes, on private repositoriesJune 1, 2026, announced April 27, 2026; also 13 premium requests per review on the Copilot meter
GitHub Code Quality scansYes, unless you use self-hosted runnersAlso a per-committer licence and AI credits from the shared pool
Automatic dependency submissionYesRuns on each commit to the default branch that updates a manifest
Code scanning workflowsYes, on private repositoriesCounted against the plan's included minutes like any other workflow
GitHub Pages buildsNoStandard-runner use is free for GitHub Pages
Dependabot jobsNoStandard-runner use is free for Dependabot
Anything on a self-hosted runnerNoSelf-hosted usage is free; a $0.002-a-minute charge was announced in December 2025 and postponed

Copilot code review. GitHub announced on April 27, 2026 that from June 1, 2026 “GitHub Actions minutes will be consumed from your existing plan entitlement for each review that is run on private repositories, with any usage beyond your included minutes billed at standard GitHub Actions rates,” and that “there are no changes to public repositories, where Actions minutes remain free.” The review is metered twice from that date: the Actions minutes it runs for, and 13 premium requests on the Copilot meter for each review of a pull request. If your quota tightened in June 2026 and nobody changed a workflow, this is the first thing to check.

Code Quality. GitHub's Code Quality billing documentation, read September 13, 2026, says “Code Quality scans run as GitHub Actions workflows and consume GitHub Actions minutes, unless you use self-hosted runners.” Its licence is per active committer and its AI features draw on the shared AI credit pool, so the scan itself is the only part on the Actions meter. On August 20, 2026 GitHub gave those scans their own workflow path: they now run on dynamic/github-code-quality/codeql and show github-code-quality as the actor, where before they shared dynamic/github-code-scanning/codeql and the github-advanced-security actor with code scanning. GitHub's own summary of the change is that “your workflow run history and your Actions usage reports now tell GitHub Code Quality runs apart from GitHub code scanning runs.” That split is a billing tool, not only a reporting one: before it, the two were one line in the usage report.

Dependency submission. GitHub's documentation for automatic dependency submission, read September 13, 2026, states that using it counts toward your Actions minutes, and that once enabled “it'll run each time a commit to the default branch updates a manifest.” It is cheap per run and frequent, which is the profile that hides inside a quota rather than inside a large invoice line.

Do larger runners use my included minutes?

No, never — larger runners are charged from their first minute, on every plan and on public repositories too. GitHub's runner pricing reference, read September 13, 2026, states flatly that “included minutes cannot be used for larger runners,” and its Actions billing documentation that they “are always charged for, even when used by public repositories or when you have quota available from your plan.”

That is the rule that converts a sensible engineering decision into an unexpected invoice. A 4-core Linux larger runner is $0.012 a minute, twice the $0.006 standard Linux 2-core rate, and it bills from minute one where the standard runner would have been covered by the quota. Moving a 3,000-minute-a-month workload from a standard runner to a 4-core larger runner on GitHub Team takes the compute line from $0.00 to $36.00, because the 3,000 included minutes stop applying at the moment the label changes.

Larger runners are also only offered on GitHub Team and GitHub Enterprise Cloud, and they are billed only for execution time, never for idle time. The full rate table for every larger-runner size is on the GitHub Actions pricing page, and the cost calculator applies it to your own minutes.

How do I set a GitHub Actions spending limit?

You set a budget, which is what the spending limit became on GitHub's current billing platform, and you tick the hard stop. Read September 13, 2026, the path is: open the billing settings for the account, organization or enterprise that owns the repositories, choose Budgets and alerts, click New budget, pick a product-level budget and scope it to GitHub Actions, enter the amount, select Stop usage when budget limit is reached, choose who receives the alerts, and click Create budget.

ChoiceWhat it does
Product-level budgetLimits spending on a single product, which is the one to use for GitHub Actions as a whole
SKU-level budgetLimits spending on one SKU within a product, for example a single larger-runner size
ScopeThe whole account or a single repository; an enterprise can also scope to one organization or one cost centre
Stop usage when budget limit is reachedTurns the budget into a hard stop rather than a warning; user-level budgets always enforce a hard stop
AlertsFire at 75%, 90% and 100% of the amount, by email and as a banner on GitHub
Alert recipientsAccount owners and billing managers by default, plus anyone you add

What happens at the limit is worth knowing before you set it, because it is abrupt. With the hard stop enabled and the budget exhausted, GitHub's documentation describes members as “blocked from using all GitHub-hosted runners until the next billing cycle or until the 'Actions' product budget is increased.” That is every hosted runner, not only the expensive ones, and it lands on a red pull request at whatever hour the budget runs out. A budget set with no hard stop is only an alert, which is the right setting for most teams until they know their own ceiling.

There is a limit you get whether you set one or not. GitHub's Actions billing documentation, read September 13, 2026, says “if your account does not have a valid payment method on file, usage is blocked once you use up your quota.” On an account with no card, the included minutes are the spending limit.

How do I find what is eating my Actions minutes?

In four passes, each answering a different question, and none of them takes more than a few minutes. All four surfaces were read on September 13, 2026; they are described here in words rather than linked, so the steps survive a navigation change better than a URL does.

QuestionWhere it is answeredWhat you get
How much am I spending, and on which SKU?Billing and licensing, then Usage, then Metered usageA graph and a per-date table with usage per SKU, units, price per unit and actual usage
Which workflow and which job is spending it?The Insights tab, then Actions Usage MetricsMinutes broken down by workflow, job, repository, runtime operating system and runner type
Is it slow, flaky or just frequent?The Insights tab, then Actions Performance MetricsAverage run time, average queue time and job failures, per workflow and per job
Which repository, user and workflow file, row by row?Get usage report, on the metered usage pageA CSV emailed to you, one row per date, SKU, repository and cost centre

Pass one: the metered usage page, for the shape of the bill

Open the billing settings for the account or organization that owns the repositories, choose Usage, then Metered usage. Set Time Frame to the current month and Group to None to see the month's budget against actual usage per day, then group by product or by SKU to see which meter is growing. Below the graph, click the arrow beside a date to open a nested table of usage per SKU, units, price per unit and actual usage for that day. This is the pass that tells you whether the problem is minutes, artifact storage, or a product that is not CI at all.

Pass two: Actions Usage Metrics, for the workflow that is doing it

From the organization or the repository, open the Insights tab and choose Actions Usage Metrics. It reports, in GitHub's own words, “how many minutes your workflows and jobs consume,” across five views: Workflows, Jobs, Repositories, Runtime OS and Runner type. Start on Jobs — it is the view that shows “which jobs are the most resource-intensive,” and jobs are the unit the rounding applies to. Runner type compares self-hosted against GitHub-hosted minutes, and Runtime OS is where a macOS or Windows job that nobody remembers adding turns up at ten times a Linux minute on macOS, or 1.7 times on Windows. The period selector offers the current week, the current month, last month, the last 30 days, the last 90 days, the last year, or a custom range of up to 100 days going back at most one year, and there is a download icon for a CSV.

Pass three: Actions Performance Metrics, to tell an expensive job from a frequent one

Same Insights tab, Actions Performance Metrics. It shows average run time, average queue time and job failures per workflow and per job. The three combinations worth naming: a long average run time with few runs is a job to make faster or move to a cheaper runner; a short run time with a very large minute total is a job that runs too often, and path filters or a concurrency group will cut it; a high failure rate is minutes paid twice, because every retry bills again. A large average queue time with a modest bill means concurrency is your constraint and not price, and no amount of workflow trimming will fix it.

Pass four: the usage report, for the row-level answer

On the metered usage page, click Get usage report at the top, specify the report details, and click Email me the report. It arrives at the account's default email address as a CSV with a download link that expires after 24 hours, and you can only request one report per account at a time. Read September 13, 2026, its columns are date, product, sku, quantity, unit_type, applied_cost_per_quantity, gross_amount, discount_amount, net_amount, username, organization, repository, workflow_path and cost_center_name, and the detailed report's rows are summed over date, SKU, organization, repository, cost centre, username and workflow path.

workflow_path is the column that earns the download. It is the only view that separates minutes your own workflow files spent from minutes another GitHub feature spent on the same quota — a Copilot code review, a Code Quality scan on dynamic/github-code-quality/codeql since August 20, 2026, or an automatic dependency submission. Sort the CSV by quantity within the Actions product, group by workflow_path, and the first three rows are usually the whole answer. If the top row is a workflow file, the fix is in the repository; if it is one of the dynamic paths, the fix is a product setting and not a workflow change at all.

What the four passes usually find

In order of how often each explains a surprise, and each is a link back to a rule above: a matrix that multiplies a short workflow by its combinations; a job on a larger runner that stopped drawing on included minutes the day its label changed; retries and superseded runs billing the same work two or three times; a macOS or Windows job at $0.062 or $0.010 a minute against $0.006 for Linux, read September 13, 2026; artifact or cache storage growing on a meter that no minutes report shows; and, since June 1, 2026, Copilot code review taking minutes out of the same quota as CI. The pricing page has the rate for every runner, and what a self-hosted runner really costs works through the alternative that has no GitHub meter at all.

What does a hosted runner service charge for the same minute?

Half as much per minute at 2 and 4 vCPU, and 45% less at 8 vCPU. Sengi charges $0.003 a minute for 2 vCPU with 8 GB against GitHub's $0.006 standard Linux 2-core minute, $0.006 for 4 vCPU with 16 GB against GitHub's $0.012, and $0.012 for 8 vCPU with 32 GB against GitHub's $0.022. Builds also finish up to 1.9× faster, so each one bills fewer minutes: together, up to 74% less per build. Per-minute billing like GitHub's, with boot and teardown never billed. No subscription, no minimum.

Each of those minutes also buys more CPU: AMD Ryzen 9 7950X3D desktop CPUs on bare metal, boosting past 5 GHz, with up to 2.75× the multi-core and 1.6× the single-core CPU of GitHub's 2 vCPU runner. On RunsOn’s open benchmark harness a production Docker image costs $0.045 a build on Sengi against $0.175 on GitHub. Cache is included free. Change runs-on to sengi-standard-2-ubuntu-2404 and merge, or give your coding agent the Sengi prompt and it opens the pull request for you. Try it free: 3,000 minutes a month, no card.

Frequently asked questions

How does GitHub Actions billing work?

GitHub bills the execution time of each job, rounded up to the whole minute, at the published rate for the runner the job ran on, and bills storage on a separate meter. On private repositories your plan's included minutes are spent first: 2,000 a month on GitHub Free, 3,000 on Pro and Team, 50,000 on Enterprise Cloud. Standard runners are free on public repositories and self-hosted runners are free. Rates and rules read September 13, 2026.

What counts as a GitHub Actions minute?

Execution time, rounded up per job. GitHub's runner pricing reference, read September 13, 2026, says it "rounds the minutes and partial minutes each job uses up to the nearest whole minute." The rounding happens once per job rather than once per workflow, so ten jobs of 30 seconds each bill ten minutes and not five. Minutes are charged to the repository owner, not to whoever pushed the commit.

Does GitHub Actions bill for queue time?

No. You are billed for the time a job executes, not for the time it waits for a runner. GitHub states of larger runners that they "are only billed at the per-minute rate for the amount of time workflows are executed on them" and that an idle larger runner costs nothing. Queue time is still worth watching, because it is the number that tells you concurrency is the constraint rather than price.

How are matrix jobs billed?

Each matrix combination is a separate job with its own rounding, so a ten-minute build across six matrix entries bills 60 minutes, not 10. At $0.006 a standard Linux 2-core minute, read September 13, 2026, that one workflow costs $0.36 each time it runs. A matrix is the single commonest reason a bill is larger than the wall-clock time anyone remembers waiting.

Do failed and cancelled runs cost money?

Yes, for the minutes they ran before they stopped. GitHub's own worked example, read September 13, 2026: "If you run a workflow that normally takes 10 minutes and it fails after 5 minutes because a dependency isn't available, you'll use 5 minutes of the repository owner's allowance. If you fix the problem and re-run the workflow successfully, in total you'll use 15 minutes." A cancelled job is billed the same way.

Are artifacts and storage included in GitHub Actions minutes?

No, storage is its own meter. Artifacts and GitHub Packages share one allowance at $0.25 per GB-month, the Actions cache is $0.07 per GB-month and custom images are $0.07 per GB-month, read September 13, 2026. Storage accrues hourly in GB-hours and is divided by the hours in the month; GitHub's example is "6,768 GB-Hours / (744 hours per month) = 9.0967 GB-Months."

Does deleting an artifact reduce my bill this month?

Not for storage already accrued. GitHub's Actions billing documentation, read September 13, 2026, says "deleting artifacts frees up space for current storage, but does not reduce your accrued storage usage." Deleting stops future accrual only, so the saving starts from the hour you delete. Artifact storage figures also lag: GitHub "updates your artifact storage usage within 6 to 12 hours."

Does Copilot code review use my Actions minutes?

Yes, on private repositories, since June 1, 2026. GitHub announced on April 27, 2026 that "GitHub Actions minutes will be consumed from your existing plan entitlement for each review that is run on private repositories, with any usage beyond your included minutes billed at standard GitHub Actions rates," and that "there are no changes to public repositories, where Actions minutes remain free." The same review also consumes 13 premium requests on the Copilot meter.

Do larger runners use my included minutes?

No, never. GitHub's runner pricing reference states that "included minutes cannot be used for larger runners," and its Actions billing documentation that larger runners "are always charged for, even when used by public repositories or when you have quota available from your plan." A 4-core Linux larger runner therefore costs $0.012 a minute from its first minute, read September 13, 2026.

How do I set a GitHub Actions spending limit?

Through a budget. In your account, organization or enterprise billing settings, open Budgets and alerts, click New budget, choose a product-level budget scoped to GitHub Actions, set the amount, and select Stop usage when budget limit is reached if you want a hard stop rather than a warning. Alerts fire at 75%, 90% and 100% of the amount and go to account owners and billing managers by default. Read September 13, 2026.

What happens when the GitHub Actions budget is reached?

Hosted-runner usage stops for the rest of the cycle if the budget has the hard stop enabled. GitHub's documentation, read September 13, 2026, describes the result as members being "blocked from using all GitHub-hosted runners until the next billing cycle or until the 'Actions' product budget is increased." Without a payment method the block arrives on its own: "if your account does not have a valid payment method on file, usage is blocked once you use up your quota."

How do I find what is eating my Actions minutes?

Start with Actions Usage Metrics under the Insights tab of the organization or repository, which breaks minutes down by workflow, job, repository, runtime operating system and runner type over a chosen period. Then request the usage report from the metered usage page for a row-level CSV with a workflow_path column, which is the only view that separates minutes a workflow spent from minutes another GitHub feature spent. Read September 13, 2026.

Cut your GitHub Actions bill by up to 74%.

Up to half GitHub’s price per minute, on 5 GHz bare metal. Builds finish up to 1.9× faster than on GitHub’s runners, so together you pay up to 74% less per build. Change one runs-on line, or give your coding agent one prompt and it opens the pull request for you.

Start free

3,000 free minutes a month, no card. See how switching works