How to choose a GitHub Actions runner provider: ten questions, no names
Picking a provider for GitHub Actions runners usually starts with a speed chart and ends with a bill nobody predicted. The chart is the least useful part of the decision. Most of what you will live with afterwards is not how fast a hello-world job ran, but how a bad day behaves: what happens to a job that cannot start, who else shares the machine, how the minutes are counted, and how hard it is to move back. So this guide is a list of questions to put to any provider, including us, with the answer we can give to each, where the answer is written down, and what a poor answer looks like. It names no provider on purpose. The questions are what matter, and a provider that cannot answer one in writing has told you something.
Where we say “ours”, the claim is one the site’s own documentation already makes, and the link goes to it. Where we say “GitHub’s”, it is GitHub’s documentation, read on 10 November 2026. Treat both as perishable.
1. What shares the machine with my job?
This is the question vendors answer least precisely, and your source code, your tokens and your build outputs pass through whatever the answer is. “Isolated” is not an answer. Ask whether two jobs, from two customers or from the same one, can ever run on the same operating system instance, what is wiped between them, and what is allowed to survive. Ours is written on the security page: each job runs in its own virtual machine, started fresh from our image and shared with no other job. When the job ends the machine is destroyed, or rebuilt from the image, and a rebuild erases its disk, memory and firmware state. What outlasts a job does so because you kept it, in the cache, the layer cache or a sticky disk. We wrote the longer version in Every job in its own virtual machine. A weak answer is a shared pool of long-lived machines cleaned by a script.
2. When does the clock start and stop, and what is rounded?
Two providers with the same rate per minute can produce different bills. GitHub’s documentation says it rounds the minutes and partial minutes each job uses up to the nearest whole minute. That is a multiplier on every short job, and a pipeline of many small jobs feels it most. Ask for the rounding rule in writing, ask whether time spent waiting for a machine is billed, and ask whether setup time counts. On ours, time is counted from when your work starts running to when it stops, and waiting for a machine is not billed. The rate for each size is on the pricing page, and it is worth reading beside our guide to where a GitHub Actions bill leaks, which does the rounding arithmetic.
3. Can I see what this month will cost before it is invoiced?
A rate card tells you what a minute costs. It does not tell you what your team will spend, and the surprise usually arrives at the end of the month. Look for three things: a usage view that updates during the month and projects forward, an alert you can set at an amount of your choosing, and a hard cap that actually stops new jobs. These are different controls, and providers often have one of them. On ours, Usage shows the month so far and a projection, an alert sends an email and stops nothing, and a spending cap stops new jobs from starting. Both are honest about their lag: CI usage reaches billing every hour, so the cap can be passed by up to about an hour of usage. The alerts and cap page says exactly how each behaves, and the calculator estimates a month before you commit to anything.
4. How many jobs run at once, and what happens to the rest?
Concurrency is the hidden price of a cheap plan. Ask what the default limit is, whether it can be raised and what that costs, and, the part most people skip, what a job over the limit looks like. A queue that says nothing is a support ticket. Ours is eight at once on the standard plan, shown on the pricing page. A job over the limit waits and its page says Waiting — you’re already running as many jobs as your plan allows; nothing is billed while it waits. You can ask for more, up to 500, after a one-off deposit that is prepaid credit and not a fee. We say the same thing the limits page does: it is an allowance, not a guarantee, because capacity is finite. Be suspicious of any provider that promises unlimited concurrency without saying where the limit really is. A related question, with its own guide, is why a job sits waiting at all: the causes of “Waiting for a runner to pick up this job”.
5. Do my caches work without rewriting the workflow?
Caching is where a moved workflow quietly gets slower. If the provider’s cache needs a different action or a different key scheme, you will touch every workflow and you will lose the entries you had. Ask whether actions/cache and the setup actions that wrap it work unmodified, whether the cache is billed, and what the limits are. On ours actions/cache works unmodified and is included in the plan, not metered. There is a separate Docker layer cache, metered by what it stores at $0.50/GB-month. A cache you have to pay for and a cache you have to rewrite for are both fine, as long as you were told before the migration and not after.
6. What can it not run?
A provider’s coverage page lists what it runs. The better test is whether it also lists what it does not. Check the platform, the architecture, the largest size, the longest job, and the things a virtual machine often cannot do: nested virtualisation for an emulator, a GPU, an interactive login. We publish ours. The runners are Linux on x64 and ARM64 and Windows Server on x64, with no macOS, no Windows on ARM, no GPU and no nested virtualisation, a job may run for 60 minutes, and the sizes run from 1 to 32 vCPU on Ubuntu x64. A workflow can mix ours and GitHub’s job by job, so the jobs we cannot run can stay where they are. The limits page and the labels page have the whole list; if a provider has no equivalent page, ask for one.
7. What does it cost to move, and to move back?
The label in runs-on is the whole switching cost for most workflows, which is also why leaving is cheap: you change it back. Ask how many lines of your configuration a provider wants to change, whether a half-migrated repository works, and what the tool that does the move does when it is unsure. Ours opens the pull request for you from the migration page; it moves a larger runner to the smallest size with at least the same vCPU and memory, leaves a label it cannot map exactly as it was and says why, and warns where a size has less disk than the runner it replaces. Because runs-on is per job, you can move one job and keep the rest where they are. A provider that wants a proprietary action in every workflow has made leaving expensive, and you should price that in.
8. When something fails, what will I be able to see?
You find out how good a provider is on a bad day, so look at the tooling for one before you need it. Does the job page separate waiting from running? Does a failure say whether your build failed or the platform did? Can you see memory, disk and CPU over the run? Is there a way into a running job, and who can switch it on? On ours the job page has Logs, Resources, Tests and Details, shows how long the job waited and how long it ran as two numbers, and separates a failed build from a failed machine. A terminal into a running job is off until an owner or admin turns it on, lasts fifteen minutes at most, and is recorded in the activity feed. See the jobs page. Weak answers here are a log and a status page.
9. What happens if a payment fails?
An odd question for a technical purchase, and the one that reveals how a provider treats you when you are in the wrong. Ask whether a failed card deletes anything, whether you are warned before compute stops, and whether your history stays readable. On ours a failed payment deletes nothing: you are told, retried on a schedule and told again, and if it stays unpaid the account is restricted rather than torn down, with existing work and history readable while new compute is held. A card is required before compute runs. The invoices and payments page has the stages, day by day.
10. What do you claim about speed, and can I check it?
Every vendor quotes a multiple, and almost none says what it was measured against, so treat every figure, ours included, as a hypothesis until you have run your own workflow. The test that cannot be gamed is yours. Take two or three of your own workflows, the slowest and the most common, run them on a trial of each provider you are considering, and compare the step you care about: the Ran for number, the waiting time and the billed minutes, not the headline. Run each more than once, on a warm cache and a cold one, because a first run and a tenth run differ for reasons that have nothing to do with the machine. The cost of that test is an afternoon. The cost of skipping it is a year of someone else’s numbers.
How to use the list
Score each provider on the ten questions with one of three answers: a specific answer you can link to, a vague answer, or none. Count the links. Questions 1, 2 and 4 are the ones most worth being strict about, because they are the hardest to change afterwards. If two providers tie, the tie-breaker is the migration: the one that lets you move one job first and move it back is the one you can afford to be wrong about.
If you want to try ours on one job, connect your GitHub organisation on the migration page and read the pull request before you merge it. The runners page has what we sell, and the guide to making GitHub Actions faster is worth reading first, because most of what a new provider is credited with is available on the one you have.