Updates to GitHub Actions pricing

We’ve read your posts and heard your feedback from our announcement, Pricing changes for GitHub Actions.

1. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.
2. We are continuing to reduce hosted-runners prices by up to 39% on January 1, 2026.

We have real costs in running the Actions control plane. We are also making investments into self-hosted runners so they work at scale in customer environments, particularly for complex enterprise scenarios. While this context matters, we missed the mark with this change by not including more of you in our planning.

We need to improve GitHub Actions. We’re taking more time to meet and listen closely to developers, customers, and partners to start. We’ve also opened a discussion to collect more direct feedback and will use that feedback to inform the GitHub Actions roadmap. We’re working hard to earn your trust through consistent delivery across GitHub Actions and the entire platform.

We're here to listen.

[fkorotkov]

Please address this issue actions/runner#620. This is by far the number one issue to properly auto-scale ephemeral runners at scale for operators like us.

[crohr]

That, or make the check run id available in the github context in workflow files so we can generate unique labels.

[h0lybyte]

Yeah, checks the date oh my, 5 years ago? nice.

[tedivm]

You can find all sorts of stuff in there- they're been so neglectful of the self hosted actions that it's embarrassing they're trying to charge for it.

They don't release containers that match the runners on the public at all. They don't handle proper rootless docker-in-docker. All issues that have come up repeatedly.

If they want to charge for things fine, but actually provide a service that doesn't require your users doing 90% of the work.

[P-r-e-m-i-u-m]

I appreciate the transparency and the decision to pause and rethink this change. Listening to the community and taking feedback seriously really matters, especially for developers and teams who depend on Actions every day. The price reduction for hosted runners is also a positive step. It’s good to see GitHub engaging directly with users and working to rebuild trust through better communication and consistent improvements. Looking forward to seeing how this feedback shapes the future of GitHub Actions.

[cquanu]

Thanks for listening

[guidestaramb-lgtm]

My opinion is that re -evaluating the efficiency and effectively manage equity for customer services and sales cloud engagement usage is being updated

[brtkwr]

Make your runners competitive vs customers hosting their own self-hosted runners.

Don't charge them the same per minute price as your own runners, that is just anti-competitive.

We are already paying for the privilege of using the "control plane" by paying for our Github accounts.

[fproulx-boostsecurity]

Well it’s still variable cost. Control plane is not free either. But definitely the pricing model they announced was not correct. They need a generous 0 cost control plane for self hosted that cover 80% of folks and then the rest needs to be billed not by the minute. More aligned with what it really costs since it’s not compute it’s mostly ingesting the logs which could be insane I’m sure people are dumbing gigabytes of junk ….

[mecaota]

I understand that it's a variable cost, but I can't accept that it's the same price as our company's minimum configuration runner. They should at least lower the price. Why should I pay a higher price for platform usage than AWS CodeBuild?

[MatthewAry]

The billing unit for self-hosted shouldn't be time based at all. The truth is that any dev with experience in systems engineering should know that while there are fixed overheads (not accounting for long-lived connections) for any given job being tracked, there are parts that are highly variable which are mostly a product of how "chatty" a runner is. We could make it so runners emit very few logs and yet under what's now the proposed billing model, it grossly simplifies these important differences.

If you have to charge, then this is how I think it should work:

• Self-hosted should NEVER be billed by minutes or count against "actions minutes"
• Self-hosted should have it's own quotas with caveats that could lead to additional charges:
  • Action runs excessively long (12 hrs?)
  • Log volume quotas per action

Something like this ☝️

Developers aren't dumb! You know this. That's why you got this reaction. The proposed billing model seemed unfair and didn't make any sense.

[dubsalot]

Self-hosted should NEVER be billed by minutes or count against "actions minutes"

💯

I agree with another poster as well - the cost of the control plane / the actions queue should be included in the cost of our enterprise.

[andresvillenas]

Thanks for listening👂

[bhswilson]

Appreciate that you are "postponing" what appears to be a foregone conclusion, giving us time to get our own plans in order.

However,

1. We already pay for the control plane, to the tune of thousands of dollars.
2. Penalizing us for running actions self-hosted because you are unwilling to sign the necessary compliance contracts is a you problem and not an us problem and not something for which we should have to pay extra.

[RohovDmytro]

Whatever the overhead, it does not cost 0.002 cents per each minute. Also, it fully breaks the real quality solutions in the ecosystem. This is something to highlight.

[ThadHouse]

The biggest issue we had with the per minute is we are a volunteer organization and are using donated self hosted hardware to run our builds. This hardware was generally a few years old and slower. The new billing made it so that running older hardware was not feasible at all, since slower builds directly result in higher costs. Essentially telling us we need top of the line hardware in order to reduce our GitHub costs, which seemed backwards to me compared to a cost per run build.

[bhswilson]

I wouldn't characterize the hosted runners as "top of the line", either.

[ThadHouse]

No, but to make the most use of the cost per minute for self hosted runners, you would need to self host top of the line hardware. Slower and older hardware has very direct costs when runs cost per minute.

Basically was actions saying if you want to self host, you better not be self hosting old hardware. Because users using that are going to get fleeced.

We'd actually love to just use the GitHub runners for our private project. 99% of our code is open source and we're happy with actions and the speed. We just have 1 private project, and it's not feasible to pay for the runners in the private repo.

[JC3]

Thanks for listening. I would accept a flat cost per job over a per minute cost. Id also like to see some benefits for Pro members.

[adiologydev]

This is a welcome update. I understand that even though we run actions on our own hardware, the logs and other artifacts are still stored on GitHub's infrastructure.

There are two ways that I can think of going about this:

1. Let us retain those logs and artifacts on our own infrastructure OR
2. Let the users opt-in for longer retention (for a reasonable cost), and make the default retention limited to N number of action runs or N number of days (free as it currently is).

This is just a quick thought, but I'm sure the community and GitHub team can come up with something that will work out for everyone in the end.

[thejhh]

There are already extra costs for storage. That should not be the reason for this fee.

[adiologydev]

There are already extra costs for storage. That should not be the reason for this fee.

I am not sure if that contains log retention for actions.

[abhi1693]

Logs do cost extra already. We had to shorten the retention of logs to not get a huge bill

[adiologydev]

Logs do cost extra already. We had to shorten the retention of logs to not get a huge bill

Well in that case, this whole plan was extremely uncalled for. I'm hoping this backlash makes them realise what not to do moving forward.

[naikrovek]

thumbs down because you are not in control of the situation and github is not your pet. i disagreed with the pricing but this response to this post is just a straight asshole move. if i could ban you from discussions on github, i would.

[overlook21]

Last update on actions/actions-runner-controller#2796 (comment)

The product owner made a bunch of promises the team never delivered on then the discussion mysteriously vanished off the face of the planet.

I suppose the purpose of this discussion is the same?

[ahatzz11]

multi-label support was announced as an upcoming feature as part of the pricing update: github/roadmap#1195

source

[overlook21]

So it really was a cash grab from the beginning, starting with the acquisition of the actions runner controller open source project.

Embrace, "extend", extinguish right?

[surgiie]

I sure hope they give this as much attention as they plan to do for the runner.

[molson504x]

I think the original announcement was kind of tone-deaf, disorganized, and it felt like it took away a huge part of why so many developers come to GitHub - because it is a developer-first and OSS-first platform. A lot of OSS projects don't have funding, which is why it's AWESOME that GitHub offers a place to host code for free, and offers so many cool tools to developers.

I think the negative reaction to the announcement was because the only justification that was made was "we're doing it to reduce the cost of GitHub hosted runners" and it never really said the truth - that a lot of organizations HAVE TO use self-hosted runners due to compliance and privacy reasons. Oh, and they do pay quite a bit to use the GH platform already.

Had the announcement said "guys this is a hella expensive feature to run even if the runners aren't run on our compute" and spelled it out, it would have made a lot more sense. Luckily, I had a hubber who I could reach out to who was able to provide that info to me.

As someone who works with a lot of enterprise customers, two recommendations for when you do this in the future:

1. BE TRANSPARENT. It's why we liked GitHub to begin with, and it's something that GH has been moving away from lately it seems........
2. Maybe start with your larger enterprise customers first, not your smaller OSS partners or free accounts. Your enterprise accounts can afford it. I've done the math with a few of mine, and it comes out to a very minimal amount of Operational Expense for them in the grand scheme of things. Your for-profit customers can afford the op-ex. Your not-for-profit customers or non-business customers probably shouldn't incur that cost. Odds are if they are running their own hardware to run actions they're doing it for a reason.

Thanks for everything that you, Hubbers, do! We appreciate you, even when we don't tell you.

[chemaper]

Sorry, but this is not only a issue with OSS projects. BTW, OSS projects have other alternatives like forgejo. "Your enterprise accounts can afford it": you must be kidding. It is not a financial problem for Github that some OSS projects choose another free alternatives. It will be a financial problem for Github that their big paying customers were unhappy.

[denysvitali]

It's good that you're doing damage control after the backlash, but I think for most of us the trust is already broken. Especially since you considered it to be a good thing to introduce the pricing change without even checking with the community whether this was a reasonable choice.

Aside from the pricing change, GH Actions is not a "premium service" that is even worth paying for. The "control plane" suffers from multiple issues (see recent problems about broker / backend problems not relaying the messages) and the GH Actions ecosystem is broken in so many ways (e.g: safe_sleep).

Personally, I'll switch to Woodpecker CI (again!) and move my repositories elsewhere. GitHub is introducing constant changes that are just harmful for their users.

I was also once a happy GitHub Copilot customer, but you ended up destroying another good product.
Whoever is calling the shots at GitHub should IMHO step down - you're ruining the company.

[intellix]

I know a company that literally just transitioned from Gitlab to Github and it's like boom one month later, another $1.8k/mo please

[MrSuddenJoy]

Thanks for listening to us. Just one question here: why cannot it be a flat price per Actions rather than per minute as of now? Wouldn't this make things easier?

EDIT:

A workflow when triggered via dispatch a.k.a UI doesn't appear on the grid unless the page is refreshed!

@tvishwanatharkin this can be easily achieved via live-updating webView. No more than 30 secs of work.......

A complex pipeline with reusable layers doesn't get cancelled from the UI no matter how many times you click the Cancel button! Apparently, the internal APIs don't use force-cancel. We're forced to call that API most of the times.

@tvishwanatharkin Thats just badly designed UX.

"If you want to monetize it, go ahead! But, make it compelling and competitive to pay for."

@tvishwanatharkin Thats main point. I agree with this OFC.

[dukxamin-beep]

Thanks for listening to us. Just one question here: why cannot it be a flat price per Actions rather than per minute as of now? Wouldn't this make things easier?

EDIT:

A workflow when triggered via dispatch a.k.a UI doesn't appear on the grid unless the page is refreshed!

@tvishwanatharkin this can be easily achieved via live-updating webView. No more than 30 secs of work.......

A complex pipeline with reusable layers doesn't get cancelled from the UI no matter how many times you click the Cancel button! Apparently, the internal APIs don't use force-cancel. We're forced to call that API most of the times.

@tvishwanatharkin Thats just badly designed UX.

"If you want to monetize it, go ahead! But, make it compelling and competitive to pay for."

@tvishwanatharkin Thats main point. I agree with this OFC.

[FleetAdmiralJakob]

Video with many insights: https://www.youtube.com/watch?v=xTSar1SEmIU

[laodongAI]

Recently, while using the GitHub Copilot service, I encountered severe unauthorized overcharging issues: there is a stark discrepancy between my actual usage amount and the deducted amount on the bill, with obvious excessive charges applied to my account.
In response to this billing problem, I submitted an official support ticket one month ago (Ticket No.: [Fill in your ticket number here]). However, to this day, no staff member has taken the initiative to contact me to communicate the situation, nor have I received any form of progress update.
Billing issues directly relate to users' property rights and interests, and are among the most critical core problems in platform services. As a globally renowned large tech enterprise, GitHub has turned a blind eye to such crucial user demands for over a month, and its abysmal work efficiency is shocking.
This disregard for users' core rights is not only irresponsible to users, but also exposes severe internal management chaos within the platform — the ticket handling process is a mere formality, and the user feedback channel is completely ineffective. In the long run, an enterprise lacking a sense of responsibility is destined to fail to win long-term trust from users.
Here, I strongly demand that the GitHub official team:
Immediately verify the detailed records of the unauthorized charges on my account and refund all overcharged amounts in full;
Assign a dedicated staff member to take over my ticket and provide a clear timeline for resolution;
Publicly explain the root cause of this incident, optimize the ticket handling mechanism, and prevent similar problems from recurring.

[samus-aran]

Hi @laodongAI

The community is unable to assist with nor escalate your ticket. It will be answered in the order it was received based on our support team's resources and the amount of tickets ahead of yours. We appreciate your understanding! In the future, please only open 1 ticket per incident.

No other Community Discussions team members will be able to provide additional help with account related questions.

[P-r-e-m-i-u-m]

I appreciate the transparency and the decision to pause and rethink this change. Listening to the community and taking feedback seriously really matters, especially for developers and teams who depend on Actions every day. The price reduction for hosted runners is also a positive step. It’s good to see GitHub engaging directly with users and working to rebuild trust through better communication and consistent improvements. Looking forward to seeing how this feedback shapes the future of GitHub Actions.

[sophiasmithastri]

Many teams rely on self-hosted runners for security and predictable builds, so a surprise pricing shift can break planning fast. If you move forward later, please publish a clear cost model, real examples, and a longer notice period.

[macintoshplus]

For security reasons, self-hosted runners must be used on private code repositories. We use private runners to build software on a volunteer basis. If we have to pay for private runners, we will have to make the difficult choice of shutting everything down or migrating elsewhere, which will incur a cost we cannot afford.

Charging for minutes on private runners is unacceptable for nonprofits.