We’ve read your posts and heard your feedback. 

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](https://github.com/orgs/community/discussions/182186) 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. 

---
__Below is the original announcement from 12/16/25__

We’re announcing updates to our pricing and product models for GitHub Actions. 

Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost. This meant that the cost of maintaining and evolving these essential services was largely being subsidized by the prices set for GitHub-hosted runners. By updating our pricing, we’re aligning costs more closely with usage and the value delivered to every Actions user,  while fueling further innovation and investment across the platform. The vast majority of users, especially individuals and small teams, will see no price increase.

We will have a GitHub Actions pricing calculator available where you will know how much you will be charged. You can see the [Actions pricing calculator](https://github.com/pricing/calculator#actions) to estimate your future costs. 96% of customers will see no change to their bill. Of the 4% of Actions users impacted by this change, 85% of this cohort will see their Actions bill decrease and the remaining 15% who are impacted across all face a median increase around $13. 

GitHub Actions will remain free for public repositories. In 2025, we saw developers use 11.5 billion total Actions minutes in public projects for free (\~$184 million) and we will continue to invest in Actions to provide a fast, reliable, and predictable experience for our users. 

## Background  
When we shipped Actions in 2018, we had no idea how popular it would become. By early 2024, the platform was running about 23 million jobs per day and our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions. 

[Our solution was to re-architect the core backend services powering GitHub Actions jobs](https://github.blog/news-insights/product-news/lets-talk-about-github-actions/) and runners with the goals of improving uptime and resilience against infrastructure issues, enhancing performance, reducing internal throttles, and leveraging GitHub’s broader platform investments and developer experience improvements. This work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform.

Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support. 

As with any product, our goal at GitHub has been to meet customer needs while providing enterprises with flexibility and transparency.

This change better supports a world where CI/CD must be faster and more reliable, better caching, more workflow flexibility, rock-solid reliability, and strengthens the core experience while positioning GitHub Actions to power GitHub’s open, secure platform for agentic workloads. 

## What’s changing?

### Lower prices for GitHub-hosted runners

Starting today, we’re charging fairly for Actions across the board which reduces the price of GItHub Hosted Runners and the price the average GitHub customer pays. And we’re **reducing the net cost of GitHub-hosted runners by up to 39%**, depending on which machine type is used.

This reduction is driven by a \~40% price reduction across all runner sizes, paired with the addition of a new $0.002 per-minute GitHub Actions cloud platform charge. For GitHub-hosted runners, the new Actions cloud platform charge is **already included into the reduced meter price.** 

Standard GitHub-hosted or self-hosted runner usage on **public repositories will remain free**. **GitHub Enterprise Server pricing is not impacted** by this change.

The price reduction you will see in your account depends on the types of machines that you use most frequently – smaller runners will have a smaller relative price reduction, larger runners will see a larger relative reduction.

This price reduction makes high-performance compute more accessible for both high-volume CI workloads and the agent jobs that rely on fast, secure execution environments.

For full pricing update details, see the updated Actions runner prices [in our documentation](https://docs.github.com/billing/reference/actions-runner-pricing).

This price change will **go into effect on January 1, 2026**.

### Introduction of the GitHub Actions cloud platform charge

We are introducing a **$0.002 per-minute Actions cloud platform** **charge** for all Actions workflows across GitHub-hosted and self-hosted runners. The new listed GitHub-runner rates include this charge. This will not impact Actions usage in public repositories or GitHub Enterprise Server customers.  

This aligns pricing to match consumption patterns and ensures consistent service quality as usage grows across both hosting modalities.

This will impact **self-hosted runner pricing starting March 1, 2026\.**

### Deepened investment in the Actions self-hosted experience

We are increasing our investment into our self-hosted experience to ensure that we can provide autoscaling for scenarios beyond just Linux containers. This will include new approaches to scaling, new platform support, Windows support, and more as we move through the next 12 months. Here’s a preview of what to expect in the new year:

#### GitHub Scale Set Client

This [new client](https://github.com/github/roadmap/issues/1192) provides enterprises with a lightweight Go SDK to build custom autoscaling solutions without the complexity of Kubernetes or reliance on ARC. It integrates seamlessly with existing infrastructure—containers, virtual machines, cloud instances, or bare metal—while managing job queuing, secure configuration, and intelligent scaling logic. Customers gain a supported path to implement flexible autoscaling, reduce setup friction, and extend GitHub Actions beyond workflows to scenarios such as self-hosted Dependabot and Copilot Coding Agent.

#### Multi-label support

We are reintroducing [multi-label functionality](https://github.com/github/roadmap/issues/1195) for both GitHub-hosted larger runners and self-hosted runners, including those managed by Actions Runner Controller (ARC) and the new Scale Set Client.

#### Actions Runner Controller 0.14.0 

[This upcoming release](https://github.com/github/roadmap/issues/1194) introduces major quality-of-life improvements, including refined Helm charts for easier Docker configuration, enhanced logging, updated metrics, and formalized versioning requirements. It also announces the deprecation of legacy ARC, providing a clear migration path to a more reliable and maintainable architecture. Customers benefit from simplified setup, improved observability, and confidence in long-term support, reducing operational friction and improving scalability.

#### Actions Data Stream

The [Actions Data Stream](https://github.com/github/roadmap/issues/1193) will deliver a near real-time, authoritative feed of GitHub Actions workflow and job event data, including metadata such as the version of the action that was executed on any given workflow run. This capability enhances observability and troubleshooting by enabling organizations to integrate event data into monitoring and analytics systems for compliance and operational insights. By providing structured, high-fidelity data at scale, it eliminates reliance on manual log parsing and empowers teams to proactively manage reliability and performance.

## Why this matters

Agents are expanding what teams can automate—but CI/CD remains the heartbeat of modern software delivery. These updates enable both a faster, more reliable CI/CD experience for every developer, and a scalable, flexible, secure execution layer to power GitHub’s agentic platform.

Our goal is to ensure GitHub Actions continues to meet the needs of the largest enterprises and of individual developers alike, with clear pricing, stronger performance, and a product direction built for the next decade of software development.

## FAQ

**Why am I being charged to use my own hardware?**  
Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost. This meant that the cost of maintaining and evolving these essential services was largely being subsidized by the prices set for GitHub-hosted runners. By updating our pricing, we’re aligning costs more closely with usage and the value delivered to every Actions user,  while fueling further innovation and investment across the platform. The vast majority of users, especially individuals and small teams, will see no price increase.

You can see the [Actions pricing calculator](https://github.com/pricing/calculator#actions) to estimate your future costs.

**What are the new GitHub-hosted runner rates?**  
See the GitHub Actions [runner pricing reference](https://docs.github.com/billing/reference/actions-runner-pricing) for the updated rates that will go into effect on January 1, 2026\. These listed rates include the new $0.002 per-minute Actions cloud platform charge.

**Q: Why is .002/minute the right price for self-hosted runners on cloud?**  
We determined per-minute was deemed the most fair and accurate by our users, and compared to other self-hosted CI solutions in the market. We believe this is a sustainable option that will not deeply impact our lightly- nor heavily-active customers, while still delivering fast, flexible workloads for the best end user experience. 

**Which job execution scenarios for GitHub Actions are affected by this pricing change?**

* Jobs that run in private repositories and use standard GitHub-hosted or self-hosted runners  
* Any jobs running on larger GitHub-hosted runners

Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.

**When will this pricing change take effect?**

The price decrease for GitHub-hosted runners will take effect on January 1, 2026\. The new charge for self-hosted runners will apply beginning on March 1, 2026\. The price changes will impact all customers on these dates.

**Will the free usage quota available in my plan change?**  
Beginning March 1, 2026, self-hosted runners will be included within your free usage quota, and will consume available usage based on list price the same way that Linux, Windows, and MacOS standard runners work today.

**Will self-hosted runner usage consume from my free usage minutes?**  
Yes, billable self-hosted runner usage will be able to consume minutes from the free quota associated with your plan.

**How does this pricing change affect customers on GitHub Enterprise Server?**

This pricing change does not affect customers using GitHub Enterprise Server. Customers running Actions jobs on self-hosted runners on GitHub Enterprise Server may continue to host, manage, troubleshoot and use Actions on and in conjunction with their implementation free of charge. 

**Can I bill my self-hosted runner usage on private repositories through Azure?**

Yes, as long as you have an active Azure subscription ID associated with your GitHub Enterprise or Organization(s).

**What is the overall impact of this change to GitHub customers?**

96% of customers will see no change to their bill. Of the 4% of Actions users impacted by this change, 85% of this cohort will see their Actions bill decrease and the remaining 15% who are impacted across all face a median increase around $13. 

**Did GitHub consider how this impacts individual developers, not just Enterprise scale customers of GitHub?**  
From our individual users (free & Pro plans) of those who used GitHub Actions in the last month in private repos only 0.09% would end up with a price increase, with a median increase of under $2 a month. Note that this impact is after these users have made use of their included minutes in their plans today, entitling them to over 33 hours of included GitHub compute, and this has no impact on their free use of public repos. A further 2.8% of this total user base will see a decrease in their monthly cost as a result of these changes. The rest are unimpacted by this change.

**How can I figure out what my new monthly cost for Actions looks like?**

GitHub Actions provides [detailed usage reports for the current and prior year](https://docs.github.com/billing/how-tos/products/view-productlicense-use). You can use this prior usage alongside the [rate changes](https://docs.github.com/billing/reference/actions-runner-pricing) that will be introduced in January and March to estimate cost under the new pricing structure. We have created a [Python script](https://docs.github.com/billing/tutorials/estimate-actions-costs) to help you leverage [full usage reports](https://docs.github.com/billing/how-tos/products/view-productlicense-use#downloading-usage-reports) to calculate your expected cost after the price updates.

We have also updated our [Actions pricing calculator](https://github.com/pricing/calculator#actions), making it easier to estimate your future costs, particularly if your historical usage is limited or not representative of expected future usage.

## Additional resources

* See the [GitHub Actions runner pricing documentation](https://docs.github.com/billing/reference/actions-runner-pricing) for the new GitHub-hosted runner rates effective January 1, 2026\.  
* For more details on upcoming GitHub Actions releases, see the [GitHub public roadmap](https://github.com/orgs/github/projects/4247).  
* For help estimating your expected Actions usage cost, use the newly updated [Actions pricing calculator](https://github.com/pricing/calculator#actions).  
* To see your current or historical Actions usage, see our documentation for [viewing and downloading detailed usage reports](https://docs.github.com/billing/how-tos/products/view-productlicense-use).  
* If you are interested in moving existing self-hosted runner usage to GitHub-hosted runners, see the [SHR to GHR migration guide](http://docs.github.com/actions/tutorials/migrate-to-github-runners) in our documentation.

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

hero-1

Resource Page for /actions/2026-pricing-changes-for-github-actions

Pricing changes for GitHub Actions

Landing Page for /actions/getting-started

GitHub Actions help you automate your software development workflows in the same place you store and collaborate on code. Individual actions are reusable pieces of code that let you build, test, package, or deploy projects on GitHub. But you can also use them to automate any step of your workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 How to get started in four simple steps
</h3>

<ol>
 <li>Click the “Actions” tab in your repository 
 GitHub Actions is tightly integrated with your code and with the rest of the experiences on GitHub.
 </li>
 <li>Choose the workflow that’s best for your type of project 
 GitHub Actions offers helpful workflow templates to get you started, including templates for Node.js, Rust, .NET Core, and more.
 </li>
 <li>Customize your workflow 
 You can start with the workflow templates that we provide, and then you can customize them to your project’s exact requirements.
 </li>
 <li>Once you’ve chosen your workflow, press the “start commit” button 
 Your workflow configuration lives in your repository, so the build definition is versioned alongside the finished code.
 </li>
</ol>

 GitHub Actions guide: <a href="https://help.github.com/en/actions">https://help.github.com/en/actions</a>
 
 Questions and answers on GitHub Actions: <a href="https://github.community">github.community</a>


<h3 style="padding-bottom: 15px; color: #586069;">
 Helpful terms to know
</h3>

 Action 
 A program that becomes a reusable component to be used in workflows. Actions can install software for the environment, set up authentication, or automate complex sets of tasks. You can find actions in the GitHub Marketplace, or create your own and share them with your community.
 

 Workflow 
 A configurable, automated process that you can use in your repository to build, test, package, release, or deploy your project. Workflows are made up of one or more “jobs” and can be triggered by GitHub events.


 Continuous integration (CI) 
 The software development practice of frequently committing small code changes to a shared repository. With GitHub Actions, you can create custom CI workflows that automatically build and test your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.


 YAML 
 YAML stands for “Yet Another Markup Language”. It’s a human-readable markup language commonly used for configuration files, especially by CI- and <a href="https://resources.github.com/devops">DevOps</a>-focused software tools. GitHub Actions uses YAML as the basis of its configuration workflows.


 Workflow file 
 The configuration file that defines your GitHub Actions workflow. This is written in YAML and lives inside your GitHub repository in the .github/workflows directory. Each file in that directory that is named with a .yaml extension will define a unique workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 Example workflow file
</h3>

```yaml
name: CI for Node.js Project
on:
 push:
 branches: [ master ]
 pull_request:
 branches: [ master ]
jobs:
 build:
 runs-on: ubuntu-latest
 name: Build and Test
 steps:
 - uses: actions/checkout@v2
 name: Check out repository
 - uses: actions/setup-node@v1
 name: Set up Node.js
 with:
 node-version: 12
 - run: |
 npm ci
 npm run build
 npm test
 name: Build and Test
```

<h4>
 An explanation of this example workflow:
</h4>

 name 
 The name of your workflow will be displayed on your repository’s actions page.


 on 
 The events that occur on GitHub that will cause your workflow to be executed. For example, you can run your workflow on push and pull_request triggers, which will let you build your code and run your tests in a <a href="https://resources.github.com/ci-cd">Continuous Integration</a> workflow. You can add additional constraints on these triggers, like running when certain files or changed or when a certain branch is pushed to.


 jobs 
 A list of the jobs that run as part of the workflow. Each job will run independently of the others, and will run on a different virtual environment. Jobs may have a name to make them easily identifiable in the UI or in logs. Jobs contain a set of steps that will be executed, in order. This workflow has a single job, the build job.


 jobs.&lt;job-id&gt;.runs-on 
 The type of runner to use to run the given job on, either a runner provided by GitHub or a self-hosted runner that you configure. GitHub provides three main types of runners: Linux (named ubuntu-latest), Windows (named windows-latest) and macOS (named macos-latest).


 jobs.&lt;job-id&gt;.steps 
 A list of the steps that will run as part of the job. Each step will run one after another, all on the same virtual environment. By default, if any step fails then the entire job will stop. In this workflow, the build job contains three steps:
 <ol>
 <li>
 The first step uses an action named actions/checkout@v2. This is an action provided by GitHub that will check out your repository onto the runner, so that it can be built and tested.
 </li>
 <li>
 The second step uses an action named actions/setup-node@v1. This is an action provided by GitHub that will set up a particular version of Node.js on the runner. Arguments can be provided to the action in the with section; in this example, the node-version argument is set to 12, which instructs the action to put Node.js version 12 in the PATH for subsequent steps.
 </li>
 <li>
 The final step runs programs on the command-line. By default, these programs will be run with bash (on Linux and macOS) or PowerShell (on Windows). A single command may be specified, or multiple commands can be specified by starting them with a leading pipe (|) symbol.
 
 In this case, a Node.js continuous integration build will be performed by running npm ci to download and install packages from the npm registry, then running npm run build to run the build script specified by the project, and finally running npm test to run any unit tests in the project.
 </li>
 </ol>

Everything you need to know about getting started with GitHub Actions

Resource Page for /actions/github-actions-cheat

GitHub Actions Cheat Sheet

By: Angela Jiang, Product Marketing Manager @Sentry

*[Sentry](https://sentry.io/welcome/) is an application monitoring platform that helps over 3.5 million developers see what actually matters, solve quicker, and learn continuously about their applications - from the frontend to the backend.*

<h2> Toolchains are complicated—developers and engineering managers are working with more tools than they probably care to count. In order to maintain efficiency in today’s world, having smart integrations in place is becoming less of a nice-to-have and more of a necessity.</h2>

At Sentry, we're focusing on [improving the developer workflow](https://blog.sentry.io/2022/05/06/workflow-2-0) and that means in part building deeper integrations with tools like Github to make it easier for developers to monitor every stage of the release cycle - giving developers a more automated deployment workflow to catch errors as quickly as code is shipped to production (with no superfluous button-clicking).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team:

 - [Sign in](https://sentry.io/auth/login/) to your Sentry account
 - Connect your [GitHub repositories to Sentry](https://docs.sentry.io/product/integrations/source-code-mgmt/github/) to begin tracking commit data
 - Import your GitHub CODEOWNERS file to [automatically map issues](https://docs.sentry.io/product/issues/issue-owners/#code-owners) to teams or people in Sentry
 - Install the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) in GitHub to automatically upload sourcemaps, manage releases in Sentry and track how the release is trending

Customers like [Forethought](https://forethought.ai/), who have growing engineering teams and are shipping continuously, often operate with limited visibility into the code they ship and ownership over who should fix what once it's released. In Forethought’s case, integrating their GitHub CODEOWNERS file with Sentry allowed them to divide up and assign responsibilities to specific teams, [reducing their time to resolution by up to 94%](https://blog.sentry.io/2022/05/02/an-engineering-managers-tips-for-scaling-teams#defining-roles).

In addition to improving issue ownership, integrating GitHub with Sentry allows customers like Forethought to: 
- Automatically monitor the health of a new release and its impacts on users with Sentry Release GitHub Actions
- Create or link GitHub issues directly in Sentry
- Predict which commit caused an issue and who is likely responsible to resolve it
- Link Sentry stack traces back to the GitHub source code to see the line of code causing an error
- Resolve issues via a pull request or commit

Let’s walk through an example of how customers typically use Sentry and GitHub together and how you can see the above in action.

After a release is deployed, you head into your [Release Health](https://docs.sentry.io/platforms/android/configuration/releases/#release-health) tab within Sentry to monitor the stability, user adoption, and issues in a release so you can identify and stop the roll out of a bad release before it impacts customers. Within Release Health, you will see historical commit details and key stats like user adoption, application usage, and crash-rates. You can also view new, unhandled, regressed issues, and related performance problems in each release. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/6B01Y7E1ynj59MPXSjHGTq/09072f16a26588f0225dcdd20f8bc188/Sentry4.png)

With the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) installed, every new release (major or minor) will be automatically recorded and [suspect commits](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps) automatically configured. Sentry will also upload the original, untransformed source code (aka [sourcemaps](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps)) which un-minifies any Javascript code that is present. You can see when a release is not trending well by looking at key metrics such as the user adoption and crash-free session rate. 

![Sentry image 1](//images.ctfassets.net/wfutmusr1t3h/6BynkLIwSS0z6L3GHO3CS0/e245a166103fb599c05df87db8f0d190/Sentry1.png)

With the GitHub CODEOWNERS file synced to Sentry’s Code Owners rules, Sentry will not only capture the issue impacting users, but will also surface the specific commit related to the issue and automatically suggest the right team member to triage the issue. This way, you no longer need to scramble to figure out who is responsible for what when critical outages occur. 

![Sentry image 2](//images.ctfassets.net/wfutmusr1t3h/6sNxO3E0qkiqcN57Ghjbi5/9d2ecb917889876a783e95016d087573/Sentry2.png)

From here, you can create a GitHub issue directly from Sentry and tag the suggested assignee to an issue.

![Sentry screen shot ](//images.ctfassets.net/wfutmusr1t3h/1mWMC7oNxUPQkSoRnS7VLq/9c68b750edb78a21e5e0e96c65b39c7a/sentry5.png)

By clicking into the Sentry error report, the developer assigned to the issue can see the stack trace and easily navigate to the relevant GitHub file that is deep linked in the stack trace to investigate the issue further. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/2GOLy1bEkMUT2PiL2D1idr/7a2b4e84ee30c62e00f7a5e3c3fc61d8/sentry6.png)

Lastly, the developer who owns the issue can quickly identify what the problem is, fix it, and open a pull request with the Sentry Issue ID included in the comments. (Sentry automatically annotates the matching issue with a reference to the commit or pull request, and, later, when that commit or pull request is part of a release, mark the issue as resolved). 

![Sentry image 3](//images.ctfassets.net/wfutmusr1t3h/5upZY2BsVxt515vikOkZqM/357c4b2f2e7154abdb90e81c3c043b84/Sentry3.png)

By integrating GitHub with Sentry, you will be able to unlock the full potential of both tools to simplify your team’s workflow, increase speed to resolution, and learn from trends to optimize code health over time. 

As we continue to strive to improve how developers ship and improve software, [we'd love to hear from you](https://github.com/getsentry/sentry/issues/34327)-what part of the workflow works well, what is completely terrible, and what can we do better?

New to Sentry and want to try it out for free? [Sign up](https://sentry.io/signup/) or try out the latest version of the Action [here](https://github.com/marketplace/actions/sentry-release).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team

Resource Page for /actions/integrating-with-sentry

Integrating GitHub with Sentry to Increase Speed to Resolution 

Join us as we explore GitHub Actions and implement a build, test, and deploy with powerful CI/CD capabilities right next to your code.

The image features a dark background with security-themed shapes in the top left and bottom right corners. The centered text reads "What is GitHub Actions?"