GitHub Actions "The hosted runner lost communication with the server"
The runner stopped exchanging heartbeats with GitHub during the job, so the backend declared the connection lost and failed the run even though your steps may have been healthy.
What this error means
A job fails partway through with "The hosted runner: <name> lost communication with the server." Logs may cut off mid-step with no error from the command itself.
The hosted runner: GitHub Actions 12 lost communication with the server. Verify the machine is running and has a healthy network connection.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
Transient network or backend blip
A brief connectivity loss between the runner and GitHub services dropped the heartbeat long enough to trip the lost-communication threshold.
Runner host became unhealthy
Memory pressure, CPU starvation, or disk exhaustion on the host stalled the agent so it could not send heartbeats.
How to fix it
Re-run and isolate the cause
- Re-run the failed job; transient drops usually clear on retry.
- Check the step running at the cut-off for memory or disk pressure.
- For self-hosted, verify host network stability and egress.
- Add timeout-minutes so a hung job fails predictably.
Use auto-retrying managed runners
Latchkey managed runners auto-retry transient infrastructure failures like a lost connection and run on right-sized, monitored capacity, so a one-off network blip is retried instead of failing the build, 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
- Treat isolated lost-communication failures as retryable.
- Keep runner hosts off memory and disk limits that stall the agent.
- Monitor host network health for self-hosted fleets.