How Much Does GitHub Actions Cost?

Published on February 5, 2026 | Prices Last Reviewed for Freshness: February 2026
Written by Alec Pow - Economic & Pricing Investigator | Content Reviewed by CFA Alexander Popinker

Educational content; not financial advice. Prices are estimates; confirm current rates, fees, taxes, and terms with providers or official sources.

Most teams don’t think about CI bills until something changes: a heavier test matrix, macOS jobs, or bigger runners. On the surface, GitHub Actions can be $0, but metered usage can become a real monthly line item once you cross plan allowances and start paying for runner time and storage under GitHub’s billing model.

The pricing story shifted heading into 2026, with runner rates updated and a proposed self-hosted platform fee discussed, then later reconsidered. That makes it more important to know what actually gets billed today: runner minutes, storage (artifacts, caches, packages), and a handful of “premium runner” edge cases that don’t behave like the usual free quota.

TL;DR: Standard runners in public repos are free, private repos get monthly included minutes and storage, and costs climb fastest when you use macOS or larger runners, run lots of parallel jobs, or let caches and artifacts accumulate for months.

GitHub positions Actions as a native automation layer for repositories, with workflows defined in YAML and executed as jobs on runners. If you need a quick refresher on how workflows, jobs, and runners connect inside the product, Workflows and actions is the cleanest starting point.

For cost purposes, the unit that matters is the runner minute. Jobs run on Linux, Windows, or macOS environments, and the simple design decision that drives cost is where you run them. GitHub-hosted environments like ubuntu-latest, windows-latest, and macos-latest are documented in Using GitHub-hosted runners, and each OS maps to a different per-minute rate.

Where readers get tripped up is assuming “public equals free” or “self-hosted equals free.” Those statements can be true, but runner class, repo type, and storage behavior decide whether your invoice stays quiet or starts moving.

How Much Does GitHub Actions Cost?

GitHub’s own documentation states that Actions usage is free for standard GitHub-hosted runners in public repositories, and also free for self-hosted runners. The official wording and boundaries are laid out in Billing and usage, which is the page most “free Actions” claims quietly depend on.

Private repositories are where billing becomes normal. Plans include a monthly quota of runner minutes and storage, and any usage above the included amounts is billed. It is not hard to stay near $0 with small Linux workflows, but the meter starts to move once you scale test time, parallelism, or use higher-priced runners.

One important nuance is that “standard runners” are not the whole menu. Larger runners and premium capacity can follow different billing rules, so a public repository can still generate charges if you intentionally choose paid runner types.

Pricing for Private Repositories

In private repos, billing is mainly driven by two meters: runner time and storage. GitHub documents how Actions usage becomes billable, how quotas apply, and how overages are calculated in GitHub Actions billing.

Instead of repeating plan numbers everywhere, this piece keeps the full plan breakdown in the table below. The practical takeaway is simple: if your monthly minutes consistently sit above your included allowance, you should treat CI as an operational cost and forecast it like any other recurring compute bill.

If you need guardrails, GitHub supports budgets and controls for metered products so a surprise spike does not run unchecked. The workflow side has knobs, but the account-side “budget” control is described in Control costs at scale.

Runner Types and Per-Minute Pricing

Rates are set by OS and runner size, and GitHub bills usage per minute, rounded up. The canonical reference is Actions runner pricing, which also spells out a frequently missed detail: larger runners are billed separately and do not use your included minutes, and they can be billed even when used in public repositories.

As a working mental anchor, Linux minutes are the cheapest, Windows minutes cost more, and macOS is usually the most expensive. In the 2026-era tables, Linux small starts around $0.002 per minute and scales with runner size, Windows often sits around $0.01, and macOS can land around $0.06 or higher depending on the runner.

Larger runners can still be a rational choice, but they are a budget lever, not only a speed lever. If a bigger runner cuts a 30-minute job to 6 minutes, your total spend can fall even at a higher rate. If it only trims a few minutes and you run it hundreds of times, it can quietly become the biggest cost driver on the account.

One concrete field case comes from the SODA engineering team behind SNKRDUNK. They describe setting a monthly GitHub Actions budget cap of $9,000 and still hitting a bill of about $18,000 during heavy usage. It is an extreme pipeline, but it demonstrates how fast CI spend can scale when you combine long jobs, parallelism, and higher-cost runners.

2026 Actions Pricing Changes

GitHub published a pricing direction update in late 2025 that framed 2026 as a year of simpler pricing and updated runner rates, with an announced self-hosted platform charge discussed for private repos, then later flagged as something GitHub wanted to reconsider. The most precise public record of that sequence is the December 2025 Actions pricing update.

GitHub’s longer-form explanation of the 2026 shift also includes a useful scale stat, noting that public repositories consumed billions of free Actions minutes in 2025. That context, plus the broad pricing goals for 2026, is captured in 2026 pricing changes for GitHub Actions. If a $0.002 per-minute platform layer ever becomes real for self-hosted minutes in private repos, a fleet running 50,000 minutes would add $100 per month before you count your own compute.

Cost Breakdown by GitHub Plan

Plan choice sets your included buckets, but it does not change how metering works. GitHub publishes the included minutes, artifact storage, and cache storage by plan in Product usage included with each plan, and subscription pricing lives on the GitHub pricing page.

Two notes keep expectations realistic. First, “storage” is not only artifacts, it includes caches, and it can include packages depending on how your org uses GitHub. Second, subscription price and metered overage are separate lines, so paying for a plan does not prevent a usage-based Actions bill.

Self-Hosted Runners

Self-hosted runners can reduce what you pay GitHub for hosted minutes, but they do not make CI free. You still pay for your own infrastructure and operations, and you still need to manage scale, security patches, and capacity. On the workflow side, GitHub documents how to route jobs to self-hosted machines in Using self-hosted runners in a workflow.

The cost trade is often about where the bill lands. You can shrink GitHub’s metered portion and grow a cloud bill, or you can stabilize costs by running predictable workloads on long-lived compute you already operate. Self-hosting is best treated as infrastructure strategy, not a pricing trick.

A counterweight is that heavy CI can turn into real cloud spend fast. Altinity’s write-up describes experiments where two days of build activity produced roughly $2,000 in AWS charges, which is not a GitHub invoice but still part of the total cost of “running Actions” when your plan is to host runners in the cloud.

Estimate Your Costs

Start by counting how many minutes you run per OS and runner size each month, subtract your plan’s included minutes, and apply the per-minute rates for what remains. Then add storage behavior, especially if you retain artifacts for long periods or rely heavily on caching.

GitHub’s billing UI can provide granular breakdowns, and you can export data for analysis. The official entry point for pulling those numbers is Viewing your GitHub Actions usage, which is where you sanity-check forecasts against real runner minutes and storage patterns.

Worked example using typical 2026-era rates: assume a team runs 12,000 Linux minutes on a 2-core hosted runner, 1,200 Windows minutes on a 2-core hosted runner, and 400 macOS minutes in a month. If the plan includes 3,000 minutes, the overage is 10,600 minutes. Using representative 2-core rates (Linux $0.006, Windows $0.010, macOS $0.062 per minute), the compute portion lands around $82.60 for that month, before any storage overage.

Reduce GitHub Actions Costs

The highest-impact move is to reduce paid minutes. That usually means tightening triggers, cutting redundant matrix runs, and canceling duplicate work. If you deploy frequently, concurrency controls can prevent multiple overlapping runs from burning minutes at the same time, and www.thepricer.org/how-much-does-github-copilot-cost/documents that mechanism in Control the concurrency of workflows and jobs.

The second lever is runner choice. If a job can run on Linux, keep it there, and reserve Windows and macOS for tests that truly need those environments. The per-minute spread between Linux and macOS is wide enough that runner selection can beat micro-optimizing a few minutes of runtime.

Hidden costs often show up in storage, especially caches. GitHub’s billing page notes that additional cache storage is priced, and the included cache amount can be exceeded, which makes old caches a recurring charge instead of a harmless performance feature. The pricing and included cache allowances are spelled out in About billing for GitHub Actions, and teams that cache aggressively should treat cache retention like a budgeted resource.

Article Highlights

If you run Actions mainly on public repositories with standard runners, costs often stay at $0. In private repos, cost becomes predictable when you track minutes by OS, choose runner sizes deliberately, and watch storage, and it becomes unpredictable when parallelism expands without guardrails.

• Standard GitHub-hosted runners in public repositories can run at $0 in runner charges.
• Private repositories get included minutes and storage, then pay per minute once quotas are exceeded.
• macOS minutes are typically priced far above Linux minutes, so OS choice is a direct cost lever.
• Larger runners can be billed separately, and they can generate charges even when used in public repositories.
• Cache and artifact storage can become quiet recurring costs if retention is long or caches grow unchecked.
• At scale, real-world CI spend can reach five figures per month when pipelines run continuously and in parallel.

Answers to Common Questions

Do I get charged for failed workflows?

Yes. Billing is based on runner time used, so failed jobs still consume billed minutes.

Are reusable workflows cheaper?

Reusable workflows can reduce duplicated work, but there is no special discount. Savings come from fewer minutes and fewer reruns.

Can I limit my monthly CI budget?

Yes. You can set account-level budgets and alerts for metered spend, and you can also enforce workflow guardrails such as concurrency limits and narrower triggers.

Are third-party action steps billable separately?

Most Marketplace actions do not add a GitHub per-use fee by themselves, but they still run on runners and consume time. Separate charges can apply when an action integrates a paid external service.

Is billing prorated by the second or minute?

Runner usage is billed per minute, rounded up, so short jobs can cost more than expected if they frequently cross a minute boundary.