GitHub Actions "The self-hosted runner lost connection"
The self-hosted runner stopped responding to GitHub during a job, so the service marked it disconnected and the job failed; the host itself is usually the problem, not your workflow.
What this error means
A running job fails when the self-hosted runner drops offline, and the Runners page shows the runner as Offline. The job log often ends mid-step with no command error.
The self-hosted runner: my-runner-3 lost connection with the server.Diagnose it: is the job queued, or is the runner gone?
A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.
- name: Runner facts
run: |
echo "runner name: $RUNNER_NAME"
echo "os/arch: $RUNNER_OS/$RUNNER_ARCH"
nproc; free -h; df -h /
echo "labels this job asked for: ${{ toJSON(job) }}"Common causes
Host network instability
Flaky egress, VPN drops, or DNS failures on the host severed the runner's persistent connection to GitHub.
Host resource exhaustion
The runner process was starved by an out-of-memory condition or full disk and could no longer maintain the connection.
How to fix it
Stabilize the host
- Check host network egress and DNS to github.com and the Actions endpoints.
- Confirm the host had free memory and disk during the job.
- Restart the runner service and verify it reconnects as Idle.
- Re-run the job once the runner is healthy.
Offload to auto-retrying managed runners
Latchkey managed runners auto-retry transient infrastructure failures and run on monitored, right-sized hosts, so a flaky self-hosted box does not fail your builds, at $0.0025/min for 2 vCPU against $0.006 GitHub-hosted.
The failures that are not your workflow
- Exit 137 is the kernel out-of-memory killer, not an application error. Check
free -habove against your peak usage. - Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
- A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
- A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.
How to prevent it
- Monitor self-hosted host network and resource health.
- Keep runners off memory and disk limits.
- Alert when a runner flips Offline unexpectedly.