In December 2025 GitHub announced two changes to Actions pricing. One was good news and went ahead. The other was announced, met a wall of customer feedback, and was withdrawn inside 48 hours.
Eight months on, plenty of blog posts still describe the withdrawn change as though it took effect. Here is where things actually stand, and how to model CI spend given that one of these decisions is explicitly unfinished.
TL;DR
- Hosted runner prices dropped by up to 39% on 1 January 2026, depending on machine type. That went ahead.
- The $0.002/minute charge on self-hosted runners, announced for 1 March 2026, was postponed and has not been reinstated. Self-hosted usage remains free as of August 2026.
- Free minute quotas are unchanged, and public repositories remain free.
- GitHub Enterprise Server is unaffected by both changes.
- The postponement is a delay, not a commitment. GitHub said it was re-evaluating, not cancelling.
What actually changed on 1 January
GitHub reduced the price of GitHub-hosted runners by up to 39%, varying by machine type. Larger and more specialised runners saw the deeper cuts.
Two things did not change, and both matter more than the headline for most teams:
- Included free minutes on each plan stayed the same.
- Public repositories continue to run Actions free on standard runners.
For teams already on hosted runners, this was a straightforward reduction with nothing to do. If your CI budget was set before 2026 and you have not revisited it, you are probably over-provisioned relative to current pricing.
What was announced, then withdrawn
The second announcement was a $0.002 per minute "Actions cloud platform charge", scheduled for 1 March 2026, applying to self-hosted runner usage.
This was a structural change, not a price adjustment. Self-hosted runners run on hardware you already pay for; the new charge was for the orchestration layer GitHub provides around them. Teams that had built large self-hosted fleets specifically to control CI cost were looking at a per-minute fee on compute they owned outright.
The reaction was immediate and negative. Within 48 hours GitHub posted that it was postponing the change to re-evaluate its approach, acknowledging that it had not brought enough customers into the planning.
The 1 March date passed with no charge introduced. As of August 2026, self-hosted runner usage remains free, and no replacement scheme has been announced.
Where that leaves your planning
The temptation is to treat this as resolved. It is not, and the language GitHub used matters: postponing to re-evaluate, not cancelling. The commercial pressure that produced the proposal has not gone away.
Practical position for a team sizing CI spend in 2026:
| Scenario | Planning stance |
|---|---|
| Mostly hosted runners | Rebaseline against the January cut. You may be over-budgeted. |
| Mostly self-hosted, small fleet | No action. Exposure is modest even if a charge returns. |
| Mostly self-hosted, large fleet | Model a per-minute charge as a risk line. Know your monthly minutes. |
| Considering a move to self-hosted | Do not build the business case on free orchestration alone. |
The last row is the one worth dwelling on. A migration to self-hosted runners justified purely by avoiding hosted-runner cost now has a weaker case than it did in 2025: hosted prices fell, and the free-orchestration assumption underpinning self-hosted savings was shown to be a policy decision rather than a guarantee.
Do you know your CI minutes?
Most teams cannot answer this, which is the actual problem the episode exposed. If a $0.002/minute charge would have been material to you and you did not immediately know by how much, that is a visibility gap independent of what GitHub decides next.
Three things worth having in place:
- Monthly minutes by repository, hosted and self-hosted separately.
- The distribution — usually a small number of repositories generate most minutes, and they are often the ones running full test suites on every push.
- Cost per merged pull request, which is the number that makes CI spend legible to people outside engineering.
Teams that measure this routinely find their largest line is not the build. It is redundant workflow triggers — the same suite running on push, on pull request, and again on merge.
Reducing CI cost without changing provider
Before restructuring your runner strategy, the cheaper wins:
- Fix redundant triggers. Concurrency groups and
pathsfilters typically cut minutes materially with no behavioural change. - Cache dependencies properly. An uncached install on every job is the most common avoidable cost.
- Right-size runners. Larger runners cost more per minute but sometimes finish disproportionately faster. Sometimes they do not. Measure rather than assume.
- Fail fast. Put the 30-second lint job before the 12-minute integration suite.
- Cancel superseded runs. Three pushes in ten minutes should not mean three full pipelines.
These apply regardless of pricing model and usually beat provider-switching on return per hour of effort.
If you are migrating to Actions
If you are moving off Jenkins or another CI system, the pricing picture is currently favourable: hosted runners are cheaper than they were, and self-hosted remains free. Size for both, and treat the self-hosted charge as a risk to model rather than a certainty to plan around.
The migration scoping itself — pipeline tiering, the automated importer's real coverage, and where the effort actually goes — is covered in our Jenkins to GitHub Actions buyer's guide.
FAQ
Did GitHub start charging for self-hosted runners?
No. The $0.002 per minute charge announced for 1 March 2026 was postponed within 48 hours of announcement and has not been introduced. Self-hosted runner usage remains free as of August 2026.
How much did GitHub Actions hosted runner prices drop?
By up to 39% on 1 January 2026, varying by machine type. Included free minutes were unchanged and public repositories remain free.
Will GitHub reintroduce the self-hosted runner charge?
Unknown. GitHub said it was postponing to re-evaluate its approach rather than cancelling, so teams with large self-hosted fleets should model it as a risk line without assuming a date.
Does this affect GitHub Enterprise Server?
No. GitHub Enterprise Server customers were explicitly unaffected by both the price reduction and the postponed charge.
What is the fastest way to cut GitHub Actions costs?
Eliminate redundant workflow triggers with concurrency groups and path filters, cache dependencies properly, and cancel superseded runs. These usually beat changing runner strategy on return per hour of effort.
Should we move to self-hosted runners to save money?
Only if you need specific hardware, internal network access or compliance isolation. A business case resting purely on avoiding hosted-runner cost is weaker after the January price cut, and free orchestration turned out to be a policy position rather than a guarantee.
Sizing a CI estate or planning a migration? First Bridge Consulting places DevOps contractors who model CI cost properly before recommending a runner strategy. See our DevOps engineering services, or tell us about your pipeline →
Related reading: Jenkins to GitHub Actions Migration · DevOps Engineer Hourly Rate 2026 · DevOps as a Service vs In-House · DevOps Engineering services
Sources
- Update to GitHub Actions pricing — GitHub Changelog (the January reduction, the announced self-hosted charge, and GitHub's postponement statement)
- Pricing changes for GitHub Actions — GitHub (official summary of what changed and what was unaffected)
- GitHub Actions pricing changes 2026 — CICDCost (timeline of the announcement and reversal)