Skip to content
compiler.dev
Start free

Hosted Runner Lost Communication With the Server

Last updated

The error The hosted runner lost communication with the server means the GitHub runner process stopped talking to GitHub while your job was running. In practice it is nearly always the runner VM being starved of memory, CPU or disk, or a step that killed or blocked the runner itself. This page ranks the causes and shows how to find which one hit you. If nothing below fits and many unrelated jobs fail at once, check the GitHub status page.

The exact message

The hosted runner: GitHub Actions 12 lost communication with the server. Anything in your
workflow that terminates the runner process, starves it for CPU/Memory,
or blocks its network access can cause this error.

The message itself lists the common causes. You cannot SSH into a finished hosted runner, so you diagnose from logs and resource use. For machine limits, see the GitHub-hosted runners reference: standard private-repository Linux runners have 2 CPUs and 8 GB RAM, checked October 2026.

Causes, most likely first

1. Out of memory

A build or test process uses all RAM, the system thrashes, and the runner agent stops responding. Sometimes you see exit code 137 instead, and sometimes just this message. Typical triggers are webpack or Next.js builds, Jest with many workers, Gradle or Maven with large heaps, and Docker builds that compile big projects.

Log memory to confirm:

- name: Watch memory
  run: |
    (while true; do date +%T; free -m | sed -n 2p; sleep 10; done) &
- run: npm run build

If memory climbs near the total before the failure, reduce parallelism:

- run: npx jest --maxWorkers=2
  env:
    NODE_OPTIONS: --max-old-space-size=4096

2. Disk full

A full disk can freeze tools and break the runner's own logging. Check with df -h and see No space left on device.

3. CPU starvation

An infinite loop, a test that forks without limit, or too many parallel compilers can leave the runner agent no CPU time. Limit parallelism (make -j2, --workers, GOMAXPROCS) and run the heaviest step with nice.

4. A step that kills or changes the runner

Scripts that run pkill, killall node, sudo shutdown, stop Docker or system services, or turn on a firewall can cut the runner's connection. Kill by specific pattern or PID, and never touch the Runner.Listener or Runner.Worker processes.

- run: pkill -f "my-test-server"   # specific, not 'node'

5. Network changes inside the job

VPN steps, iptables rules and /etc/hosts edits can block the runner's outbound connection to GitHub. If you must do these, allow GitHub's endpoints; IP ranges are in the meta API.

6. Self-hosted runners and spot instances

On self-hosted or autoscaled runners the VM may be preempted, rebooted by an update, or lose network. Use ephemeral runners, make sure the host never sleeps, and read the runner's _diag logs for the real reason. The message is the same, but the fix is on your infrastructure.

7. A GitHub incident

If many unrelated workflows fail at once, it may be GitHub. Re-run when the incident ends.

How to diagnose

  1. Open the failed run and note the step that was running when it died. That step is the likely culprit.
  2. Turn on debug logging by setting the secret or variable ACTIONS_STEP_DEBUG to true. See enabling debug logging.
  3. Add the memory and disk logging above, and re-run.
  4. Try the same job with lower parallelism. If it passes, resource pressure is the cause.

Fixes by outcome

  • Memory is the problem and tuning is not enough: use a machine with more RAM. A GitHub larger runner works, as does a provider such as compiler.dev, whose default Linux machine is 8 vCPU / 16 GB with a fresh VM per job. See pricing.
  • A specific step kills the runner: change it so it targets only its own processes.
  • Intermittent with no clear cause: re-run, and if it repeats, contact GitHub Support with the run URL.

A retry wrapper is a stopgap for a flaky step, not a fix:

- uses: nick-fields/retry@v3
  with:
    timeout_minutes: 15
    max_attempts: 2
    command: npm test

How to prevent it

  1. Set memory limits on tools (NODE_OPTIONS, -Xmx, GRADLE_OPTS).
  2. Cap parallel workers to the CPU count of the runner.
  3. Split big builds into separate jobs rather than one very long job (see time limits and timeout-minutes).
  4. Log memory and disk so you see trends before a failure.
  5. Never run broad pkill commands.

FAQ

Is "lost communication with the server" a GitHub outage?

Sometimes, but usually your job exhausted memory, disk or CPU. If other repositories fail at the same time, check the status page.

Why does it happen only on some runs?

Memory and disk use vary with test order, cache state and input size. A job near the limit fails intermittently.

Do I pay for the failed run?

Minutes used until the failure are billed like any other. See GitHub Actions pricing.

Is it the same as exit code 137?

They share causes, mostly out of memory, but differ in what you see. Exit 137 means one process was killed. Lost communication means the whole runner stopped responding.

Related