GitHub Actions "lost communication with the server" - Runner Dropped
The control plane stopped hearing from the runner mid-job and marked the work failed. The runner crashed, lost its network, or was reclaimed - an infrastructure event, not a problem with your code.
What this error means
A job fails with The runner has received a shutdown signal or lost communication with the server, often abruptly with no application error. The runner went away while the job was still running. Re-running on a healthy runner succeeds.
The self-hosted runner: build-runner-7 lost communication with the server.
Verify the machine is running and has a healthy network connection.Common causes
The runner host crashed or was reclaimed
An OOM at the host level, a kernel panic, or a spot/preemptible reclaim takes the runner offline mid-job, so the control plane loses its heartbeat.
Network partition between runner and control plane
A transient network drop between the runner and the orchestrator stops the heartbeats. The control plane cannot tell a partition from a dead host, so it fails the job.
How to fix it
Retry the job
- Re-run the workflow - a lost runner is transient and a fresh runner usually completes the job.
- If it recurs on the same host, check that host’s memory, disk, and network health.
- For self-hosted fleets, ensure runners auto-recover and rejoin after a drop.
Stabilize the runner host
When this repeats, look for host-level resource exhaustion or flaky networking.
dmesg -T | tail -50 # kernel panics / OOM at host level
df -h && free -m # disk/memory pressure on the hostHow to prevent it
- Run on stable capacity for jobs that cannot tolerate interruption.
- Monitor self-hosted runner host health (memory, disk, network).
- Make jobs idempotent so a lost-runner retry is safe.