How Github Actions Fits Into Github
You’ve been convinced (or at least given good reasons) to use GitHub Actions. Before you write a single line of pipeline configuration, it’s worth knowing exactly where this tool lives inside GitHub’s interface, and how you’ll actually get billed for using it. Neither of these requires any YAML — this is purely orientation, so that when the hands-on chapters start, none of this is a surprise.
Finding Actions in the GitHub UI
Every repository on GitHub has an Actions tab, sitting alongside the tabs you likely already know — Code, Issues, Pull Requests, and so on. This is your control center for everything CI/CD-related in that repository.
From the Actions tab, you can:
- See a history of every workflow run — every time a pipeline has been triggered, whether it succeeded or failed, and how long it took.
- Click into any individual run to see its full log output, job by job and step by step, which becomes your primary debugging tool once you’re actually writing workflows.
- Manually trigger workflows that are configured to allow it, without needing to push a new commit.
- Re-run a failed workflow, either entirely or just the jobs that failed, without re-running everything that already succeeded.
- Manage secrets and variables — values like API keys or configuration flags that your workflows need but that shouldn’t be hardcoded into a YAML file anyone with read access to the repo could see.
Nothing about the Actions tab requires you to leave GitHub or authenticate anywhere else. It’s just another view into the same repository, which is a direct consequence of what made chapter 4’s case for GitHub Actions in the first place — it isn’t bolted on, it’s built in.
Tip
Once you start writing real workflows in later chapters, the Actions tab’s log viewer will become one of your most-used tools. Get comfortable with the idea that “did my workflow work?” always has an answer one click away, in the same tab.
How Billing Actually Works
This is the part that tends to cause the most confusion for people new to GitHub Actions, so it’s worth being precise.
Public repositories are free, full stop. If your repository is public, standard GitHub-hosted runners cost nothing unless you are using large runners and have no minute cap. This is a large part of why so much open-source CI runs on GitHub Actions — there’s no metering to think about at all.
Private repositories get a monthly allowance of free minutes, and the size of that allowance depends on your GitHub plan (Free, Pro, Team, Enterprise) — higher-tier plans include more minutes per month. This allowance resets at the start of each billing cycle; unused minutes do not carry over to the next month.
Different runner operating systems consume your allowance at different rates. A minute spent on a Linux runner counts as one minute against your quota. A minute on a Windows or macOS runner counts as more than one minute against that same quota, because those runners are more expensive for GitHub to provide. This means a workflow that “takes 10 minutes to run” can eat very different chunks of your monthly allowance depending purely on which operating system it ran on — something worth remembering once you’re choosing runners in later chapters, rather than defaulting to whichever OS without thinking about it.
Going over your included minutes bills you per minute, at a rate that also varies by runner OS. You can set a spending limit in your account settings — including a limit of $0 — which simply stops workflows from running once your free allowance is exhausted, rather than silently charging you.
Self-hosted runners — machines you provide and register yourself, instead of using GitHub’s hosted infrastructure — are a separate story covered properly much later in this course. For now, the practical summary is: running your own infrastructure lets you sidestep GitHub’s per-minute compute charges for the actual runner, though you take on the cost and responsibility of maintaining that infrastructure yourself.
Warning
Exact per-minute rates and included-minute allowances are the kind of detail GitHub revises periodically — this course won’t hardcode specific dollar figures for that reason. Before you’re managing a real billing-sensitive workflow, check GitHub’s own billing documentation for current numbers rather than relying on any number you read here or elsewhere that might be out of date by the time you need it.
Why This Matters Before You Write Any YAML
It’s tempting to skip straight past billing mechanics and get to the “real” work of writing pipelines. Two reasons not to:
First, minutes add up faster than you’d expect once a team is running tests on every push and every pull request, potentially across multiple operating systems. Understanding that Windows and macOS runners cost more against your quota than Linux ones is the kind of thing that’s much cheaper to know upfront than to discover from an unexpectedly large bill.
Second, the Actions tab is where you’ll live for the rest of this course in a very literal sense — it’s where you’ll watch your first workflow run, where you’ll debug your first failure, and where you’ll eventually manage secrets for deployments. Knowing your way around it now means the hands-on chapters starting in the next section can focus entirely on what you’re building, not on where to find things.
Note
The next chapter closes out this section with the vocabulary — workflows, jobs, steps, runners, actions, and events — that every remaining chapter in this course will use without re-explaining. It’s worth reading closely even though, like this one, it still has no YAML in it.