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.

[warasingh]

ขอโทษถ้าถามผิดที่นะครับขออนุญาตสอบถามครับขออนุญาตสอบถามนะครับในชุมชนถ้าเกิดผมถามผิดที่รบกวนฝากไปถามผู้ที่เกี่ยวข้องด้วยนะครับในชุมชนน่ะคิดหาดใหญ่ช่งบญนะถ้าได้เหรียญก็จะมาบริจาคอยู่เหมือนจับเวลาอะไรสักอย่างให้ทำให้มันเสร็จเหมือนกับหน่วยงานทั่วไปเวลาไปติดต่อสิครับทำเสร็จแล้วค่อยคิดค่าธรรมเนียมกันพวกคุณน่ะจะปล่อยให้มันเสียเวลาไปแล้วก็ทำไม่เสร็จแล้วก็ดึงๆจนกี่วันกี่วันก็ไม่เสร็จอย่าลืมนะครับติดต่อกลับไปด้วยถ้าไม่มีฟังก์ชันที่ช่วยเหลือจนเสร็จส

แค่คำว่าให้ส่งตั๋วไป okx แล้วเอาเงินเข้าบัญชีแล้วก็ย้ายไปที่บิดขับให้หน่อยเนี่ยตีโจทย์อย่างนี้ไม่ได้ทั้งนั้นมีตัวอย่างตั๋วมีอะไรให้หมดทุกอย่างตีโจทย์แค่นี้ไม่ได้ถามวนอยู่นั่นแหละสุดยอดครับผมรบกวนช่วยส่งต่อกับผู้พัฒนาสร้างจิตขับด้วยนะครับอันดับ 1 ของโลกครับผม

[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

[Ryangr0]

If this actually happens, I'm going to simply move away all of my projects and those of my clients to a competitor. This kind of business strategy is unethical and those that defend or work on this should be ashamed of themselves. Don't you think you're making enough money with seats? I'm paying upwards of 100 a month for simply having users on your platform. This broke the camel's back. Github actions is turning from a succes story into a total nightmare.

[AJMTSolutions-Admin]

Do NOT add a fee back in for self hosted runners. I will switch immediately to Jenkins.

[molexx]

Please stop applying breaking changes. Whilst they might well be 'best practice' and you might think you've informed us about them in plenty of time, real-world evidence shows this causes disruption and unhappy users.*

We use Actions to deploy to production, and if we need a production deployment we NEED a production deployment, I do not want to take several hours out to investigate, fix and test changes to our action that was stable yesterday because of a requirement change you have force-applied to us. Whether you allegedly warned anyone about it months ago or not.

Not following 'best practice' is my lookout, I'll sign whatever you want me to sign to allow that. If that means the ability to pin runner image release versions so they get out of date then so be it. Warning me is good. Spam my admin/account owner if you like, perhaps that will get me some time allocated. But breaking my production builds is not cool.

*Here's an example, note the 160+ mentions triggered by the implementation date, not the announcement date. And unanswered pleas for it to not happen again.
actions/runner-images#9692

[tvishwanatharkin]

Well, IMHO GitHub has to figure out where it stands as compared to other products in terms of its control plane's DevX/UX. Better to make it competitive before charging for it! I can share some basic stuff that it lacks.

• It took years to develop a feature to pin workflows on the UI! :)
• A workflow when triggered via dispatch a.k.a UI doesn't appear on the grid unless the page is refreshed!
• 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.
• Above issue severely dents the concurrency group's functioning when
  cancel-in-progress: true because it can't cancel an in-progress workflow immediately. So, the latest workflow waits in the queue as the previous one couldn't be cancelled. Defeats the purpose of entire feature.
• Scheduling issues are frequent where the job is put on an indefinite wait though a runner is available.
• runs-on doesn't support OR condition. Why should the choice of runners be made only with a narrowing condition? Isn't runs-on: siteA || siteB possible? Yes, one can achieve it with other constructs. But, why isn't there an easier way?
• If I have a complex workflow with 3 or 4 reusable layers, GitHub absorbs everything into a single execution graph which is OK. But, what about the metadata visualization? One who troubleshoots the failure has to drill down like a snail to open the affected workflow!! Can't the UI display a basic tree or breadcrumb of underlying repos and workflows that were used to resolve the graph? Would love to have them highlighted on the UI with soft boundaries.
• A GitHub user has no way to see the Inputs passed to trigger a workflow run !! We have many workflows whose first step is to print the inputs. We feel so betrayed to do it. Is it such a difficulty to display the inputs of a workflow run?? You must honestly look at the UI of Jenkins which was built a couple of decades ago.
• Workflow Dispatch form is crude and of stone age. A small form appears at the right top :) If there are 7-8 inputs with elaborate description, it's so cumbersome to fill it. An input form should display both id and description. One who runs the workflow MUST know the precise input parameter instead of just the description.

You're Microsoft guys! Can't go wrong with the UX whatsoever. There are more observations! However, the point I would like to make is very simple - "If you want to monetize it, go ahead! But, make it compelling and competitive to pay for."

[dukxamin-beep]

Okay

[abhi1693]

I would love to see improvements to runs-on parameter too. It's too restricted at the moment

[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.

[Srichon6672]

https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Forgs%2Fcommunity%2Fdiscussions%2F182186%3Futm_source%3Dtokenpocket&utm_source=tokenpocket

[chhieanchhang-gif]

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.

https://github.com/orgs/community/discussions/182186#discussion-9257766

[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.