What your GitHub Actions bill actually charges you for

A GitHub Actions bill is a sum of individually priced line items, each identified by a billing SKU such as a runner minute, a storage gigabyte-month, or a per-seat license, and every total the tool on this page shows you is read directly from those line items in your own usage report rather than recomputed from a rate table anywhere on the page.

This page explains what each column in that export means, what GitHub actually charges per runner-minute today, and how to read a github actions cost by workflow breakdown once you upload your own usage report to the tool below.

Reading your usage report: gross, discount, and net

A GitHub enhanced-billing usage report is a CSV with a required and an optional set of columns. Every row needs a date, a SKU, a gross amount and a net amount to be recognized as a usage report at all; everything else is optional context that degrades to a blank value rather than causing an error.

Gross cost is the pre-discount list price of a billing line — quantity multiplied by the list rate GitHub sets for that SKU — while net cost is what GitHub actually charged after subtracting any discount, such as a free-tier credit or a negotiated rate, and the relationship between the two is the identity gross minus discount equals net, which every correct usage report export satisfies.

Date

The calendar day the usage occurred.

SKU

The billing line-item identifier — which product, runner, or resource was used, such as "Actions Linux 2-core."

Gross amount

What that line item would cost before any discount is applied — quantity multiplied by GitHub's list rate.

Net amount

What GitHub actually charged for that line item after any discount — this is the number that lands on the invoice.

Product

The top-level GitHub product the charge belongs to, such as Actions, Packages, or Codespaces.

Quantity

How many units of the SKU were consumed, such as minutes or GB-hours.

Unit type

The unit the quantity is measured in — minutes, GigabyteHours, user-months, and so on.

Discount amount

The dollar amount subtracted from gross to reach net — free-tier credit, included-usage allowance, or a negotiated discount.

Organization

The GitHub organization the usage is billed under.

Repository

The repository the usage is attributed to, when GitHub's export can attribute it.

Cost center

The internal cost-center label an organization assigned to this billing line, if cost centers are configured.

Workflow path

The file path of the GitHub Actions workflow that generated the charge, such as .github/workflows/ci.yml, when attributable.

Workflow name

The human-readable name of that workflow, when attributable.

What GitHub actually charges per runner-minute

GitHub retired the classic Linux-times-one, Windows-times-two, macOS-times-ten minute-multiplier model that used to describe runner pricing, and now publishes flat, OS-and-core-count-specific per-minute USD rates for each runner SKU instead, with no multiplier arithmetic layered on top of those published rates.

The table below lists the per-minute rate for every runner SKU the fixtures and dummy report bundled with this tool exercise. The rate divided by Linux 2-core baseline column is a ratio this page derives for readability, not a multiplier GitHub itself publishes.

Source: Actions runner pricing, docs.github.com.

Not every billing SKU in a usage report is a runner minute. The table below lists every SKU string the fixtures and dummy report bundled with this tool exercise, and whether it is priced per runner-minute at all.

Storage and Codespaces usage are priced on entirely different units — per gigabyte-month or per hour, not per minute — so they are listed separately below rather than folded into the runner-minute table above.

Where your GitHub Actions cost by workflow comes from

Every usage row that GitHub can attribute to a workflow carries a workflow path and a workflow name. Grouping the gross cost the report itself contains by that workflow path, then sorting by gross cost, produces a github actions cost by workflow breakdown: the workflows spending the most CI budget, ranked, without recomputing any figure GitHub did not already provide in the export.

This is the most useful cut for most teams, because a workflow — not a repository or a day — is usually the unit a team actually changes when it wants to reduce CI spend. A workflow file is something an engineer edits directly, so a per-workflow ranking points straight at the change that would lower the bill, in a way a per-day total or an org-wide figure cannot.

The breakdown also lists which repositories each workflow ran in and its total billable minutes alongside its gross cost, so a workflow that looks expensive because it runs constantly reads differently from one that is expensive because a single run is slow.

Breaking cost down by repository

A per-repository view matters more than a per-workflow view when an organization spans multiple repositories and needs to charge cost back to a team or a cost center, rather than to a single CI pipeline. The repository breakdown sums the same gross-cost figures the workflow breakdown does, grouped by repository instead of by workflow.

This view answers a different question than the workflow breakdown: not which pipeline to optimize, but which team or product line is actually driving the bill, which is the number a cost-center chargeback conversation usually needs first.

Projecting your run rate

The projected monthly run rate takes the net cost of the days already covered by an uploaded usage report and extrapolates it to a thirty-day month by dividing net cost by days covered and multiplying by thirty, which answers what the current month is on pace to cost rather than promising a final, guaranteed bill.

A short report window makes the projection noisier: a report that only covers three days will extrapolate a single unusually busy or unusually quiet day across the rest of the month, so the projection gets more reliable the more days of usage it is given to work from.

Frequently asked questions