Monitoring Usage and Billing
Every workflow run in this course has been free to trigger — but “free” has limits, and the moment you’re running CI regularly across real repositories, it’s worth knowing where those limits live and how they’re actually calculated. This is a tour, not a hands-on exercise: there’s no repo work here, just knowing where to look before a bill or a hard stop surprises you.
Where Usage Lives
For a single repository: Settings → Actions → General shows basic controls, but the actual consumption numbers live at the account or organization level, not per-repo — GitHub tracks Actions minutes and storage against the billing account that owns the repository, not the repository itself.
For a personal account: go to your profile settings, then Billing and licensing → Usage (or Plans and usage, depending on account type). This shows minutes used so far in the current cycle, broken down by runner operating system, alongside Actions storage usage (artifacts and caches).
For an organization: Organization settings → Billing and licensing shows the same breakdown at the org level, plus, depending on plan, a view of usage by repository — useful for spotting which repo or workflow is actually driving the number up when a team shares one pool of included minutes.
Note
Exactly which menu items appear, and their precise wording, shifts periodically as GitHub reorganizes its settings UI — if a menu item mentioned here doesn’t match what you see, look for “Billing” or “Usage” near account or organization settings; the data itself hasn’t moved even when the label has.
How Minutes Are Actually Calculated
The number that matters isn’t wall-clock time — it’s billable minutes, and two things separate the two.
First, GitHub rounds each job’s duration up to the nearest minute. A job that finishes in 12 seconds still consumes a full minute; there’s no fractional billing.
Second, and more consequential: not all runner minutes cost the same. Each operating system carries its own multiplier against the Linux baseline:
| Runner OS | Minute multiplier |
|---|---|
| Linux | 1× |
| Windows | 2× |
| macOS | 10× |
That means a 10-minute job on a macOS runner draws down 100 minutes from your included allowance — the same as ten separate 10-minute Linux jobs. This is the single most common source of “why did our minutes run out so fast” surprises: a workflow that looks cheap because it only runs for a few minutes can be quietly the most expensive thing in the account if it’s running on macOS. Since this course’s pipelines have all run on ubuntu-latest, none of them have been hit by this — but it’s worth knowing before you add a macOS or Windows leg to anything, including a matrix build from earlier in the course.
Self-hosted Runners Aren’t Automatically Free
It’s tempting to think of self-hosted runner time as sitting outside this whole system, since you’re paying for the machine directly rather than per-minute through GitHub. That used to be entirely true, but no longer is. As of March 2026, GitHub introduced a small per-minute platform charge — $0.002/minute at time of writing — that applies to self-hosted runner usage on private repositories, on top of whatever the underlying hardware costs you. That usage counts against the same included-minutes allowance as GitHub-hosted runner time, rather than being billed entirely separately.
The exception that matters most for a course project like this one: runner usage on public repositories remains free, for both GitHub-hosted and self-hosted runners. If the devstuffs practice repositories are public, none of this changes anything for you directly — but it’s exactly the kind of detail worth knowing before recommending a self-hosted setup to a team running private repos, since “self-hosted runners are free once you own the hardware” stopped being accurate the moment that charge took effect.
Tip
This is a genuinely recent change, and pricing details like this are exactly the kind of thing that drifts over time. If the numbers here look different from what your account’s billing page shows, trust the billing page — check GitHub’s own billing documentation for the current figures rather than assuming this chapter is still exactly right.
Where Limits And Alerts Live
Two more things worth knowing exist, without needing to touch them for this course:
- Spending limits, under Billing and licensing → Spending limits at the account or org level, let you cap how much GitHub Actions usage is allowed to cost beyond your included minutes — anywhere from a hard $0 (workflows simply stop running once the free allowance is exhausted) up to a specific dollar ceiling, or unlimited.
- Usage alerts, configurable in the same billing area, notify you (or the org’s billing contacts) as usage approaches a threshold you set, so a runaway workflow or an unexpectedly busy month doesn’t go unnoticed until the invoice arrives.
For a solo learning project, a $0 spending limit paired with the free monthly minute allowance is a reasonable default — it guarantees you never get billed by accident, at the cost of workflows simply failing to start once you’ve used up the free allowance for the month, rather than continuing and costing money. For a team running production deploys, that same $0 default would mean CI silently stops working the moment the free minutes run out — which is its own kind of incident. Knowing which of those two failure modes you’d rather have is worth deciding deliberately, rather than discovering it the first time you hit the limit.