Moving a GitHub Actions job onto your own machine changes an important dependency: GitHub no longer has to provide the compute. You choose the image, capacity, network placement, and lifecycle of the worker.
It does not move the workflow out of GitHub Actions. The run still has to be created, evaluated, queued, and assigned by the Actions service before a self-hosted runner receives anything to execute.
That distinction is easy to miss because the runner is the part you can see and operate. During an Actions outage, however, a perfectly healthy machine can sit idle while a release remains queued upstream.
A self-hosted runner is a worker, not a scheduler
GitHub's own self-hosted runner reference describes the runner application as connecting to GitHub Actions to receive job assignments. The routing rules also live on the service side: GitHub finds an online, idle runner whose labels and group match the job, assigns the job, and sends it to that runner.
If the assigned runner does not pick up the job within 60 seconds, GitHub re-queues it. If no matching runner is available, the job stays queued and eventually fails after 24 hours. Your machine participates only after GitHub has produced an assignable job and selected it.
The same boundary applies to the surrounding workflow. Event admission, job dependencies, matrix expansion, conditions, environment gates, token issuance, cancellation, and conclusions all coordinate through the Actions control plane. Owning the last machine in that chain does not transfer ownership of the chain.
What self-hosting protects—and what it does not
Self-hosting is useful when the risk lives in the execution environment. It can provide predictable capacity, specialized hardware, a controlled image, access to a private network, or a cost model that fits steady workloads. Those are real operational reasons to run your own fleet.
An Actions control-plane incident is a different failure. New runs may not appear, jobs may not leave the queue, assignments may not reach connected runners, or status and logs may stop advancing. A job that was already assigned might continue executing locally, but that does not make the workflow lifecycle independent.
- You ownMachines, images, capacity, local networking, scaling, patching, and the runner process.
- Actions still ownsRun creation, job routing, assignment, workflow state, and the coordination around execution.
- You also addFleet health, upgrades, persistence risk, autoscaling, and incident response for the worker layer.
An independent control plane changes the dependency graph
A genuinely independent CI path parses the workflow, stores the run graph, admits jobs, provisions machines, streams logs, retains artifacts, and records conclusions without calling GitHub Actions. Its runners receive work from a different scheduler, not from the same Actions queue through different hardware.
For a GitHub-backed repository, that path can still need GitHub to deliver an event, serve the requested commit, mint an installation token, and accept a Check Run. If GitHub Actions is degraded while those repository and App surfaces remain healthy, the independent scheduler can continue. If GitHub itself is broadly unavailable, the source dependency remains.
That is not total independence, and it should not be marketed as such. It is a narrower, testable separation: the workflow control plane and execution fleet do not share the GitHub Actions failure domain.
Build a fallback around one release path
Do not begin by duplicating every workflow. Choose one Linux release path whose delay has a clear cost. Check its Actions, permissions, services, artifacts, environments, and deployment assumptions against the alternate system, then run both paths against the same immutable commit until their outputs agree.
Write down the failover rule before the incident. A useful rule names the health signal, the maximum acceptable queue delay, the person authorized to switch, and the mechanism that prevents the original and fallback deployments from racing when the primary recovers. Deployment idempotency and an external environment lock matter more than a heroic runbook.
Drill the path while both providers are healthy. Verify source access, secret release, artifact integrity, deployment identity, logs, and the final repository status. A backup you have only configured is still a hypothesis; a backup you have exercised is an operating capability.
Self-hosted runners still have a clear job
None of this makes self-hosted runners a mistake. They solve execution problems: locality, hardware, capacity, customization, and sometimes economics. They can also reduce exposure to an incident limited to GitHub-hosted runner capacity or images.
They simply do not solve control-plane continuity. Ask two separate questions during architecture review: where does the job execute, and who decides that the job exists? The first is a runner decision. The second is the outage boundary.
Primary references
- GitHub: Self-hosted runners referenceCommunication requirements, assignment routing, re-queue behavior, and queue limits. ↗
- GitHub: Troubleshooting workflowsGitHub's workflow and runner troubleshooting entry point, including platform status guidance. ↗
- GitHub StatusThe public incident surface for GitHub Actions and the GitHub services around it. ↗