# GitHub Actions "The hosted runner lost communication with the server"

> Fix GitHub Actions "The hosted runner lost communication with the server" - a network or backend drop severed the runner from GitHub mid-job.

Source: https://latchkey.dev/learn/github-actions/github-actions-runner-lost-communication-with-server  
Updated: 2026-06-26

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.

## 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.

```.github/workflows/ci.yml
- 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) }}"
```

> If the job sits in `queued` and never picks up, no runner matches every label you listed. Labels are ANDed: `runs-on: [self-hosted, linux, gpu]` needs one runner carrying all three, not three runners carrying one each.

## The failures that are not your workflow

- Exit 137 is the kernel out-of-memory killer, not an application error. Check `free -h` above 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.

## FAQ

### What causes GitHub Actions "The hosted runner lost communication with the server"?

There are 2 common causes: transient network or backend blip and runner host became unhealthy. A brief connectivity loss between the runner and GitHub services dropped the heartbeat long enough to trip the lost-communication threshold.

### How do I fix GitHub Actions "The hosted runner lost communication with the server"?

There are 2 fixes depending on which cause you have: re-run and isolate the cause and use auto-retrying managed runners. Work through them in order, since the first is the most common.

### What does GitHub Actions "The hosted runner lost communication with the server" actually mean?

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.

### How do I stop GitHub Actions "The hosted runner lost communication with the server" happening again?

Treat isolated lost-communication failures as retryable. The prevention section lists 3 changes that keep it from recurring.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt