GitHub Actions · Checked November 3, 2026

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

The runner stopped reporting to GitHub while the job was running, and GitHub gave up on it. Unlike a shutdown signal, the runner had no chance to say why, so the log is often missing. Most cases come from the job itself using up the machine; a few do not.

What it looks like

The annotation on the job, from a public run on November 2, 2026 (runs-on: windows-2025):

The hosted runner 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 job fails. The step that was running stays "in progress" and the post steps never start.
• The log is often gone: downloading it returns 404 (BlobNotFound). In that run the step had captured its output to a file to print at the end, so nothing of it reached GitHub (soldr #4072).
• GitHub reports it some minutes after the runner died. One project measured about 10 minutes: the runner died at 19:50:58 and the message came at 20:00:36, so the job looks longer than the work it did (hyperskill-plugin #67).
• On a self-hosted runner the message starts "The self-hosted runner lost communication with the server" (same report).

Why

• Memory. A security agent added as a step grew by about 200 MiB a minute under a fork-heavy test run until the 16 GB runner died; without it, the same shards stayed at 3 to 4.2 GB (boost #1301). On self-hosted runner pods, two jobs of 9 to 10 GB each shared a node with about 14 GB available, and the one further along was killed (hyperskill-plugin #67). The same overload can instead end with "The runner has received a shutdown signal".
• Disk. A repository with about 53 GiB of tracked files filled the runner's disk; the runner could not even write its own log ("No space left on device"), and one of those jobs ended with this message (single-stock-investments #1473).
• CPU. On Windows, one project now runs its heavy work at below-normal priority so that it cannot starve the runner process (soldr #4072).
• Network: anything in the job that blocks the runner's own connection to GitHub, as the message says.
• Now and then, nothing in the workflow. One project found 2 such jobs in a sample of 200 failed runs; the job had got its runner in 3 seconds, and a probe of the same work peaked at 5.9 of 16 GB of memory (omni #3517).

Keep some evidence

• Print as you go, not at the end: unbuffered output (PYTHONUNBUFFERED=1 for Python) and a line at the start and end of each phase (soldr #4072).
• Because the whole log can be lost, a measurement written to the log may not survive. One project posted memory, disk and process snapshots to a separate check run every 10 seconds, so the data outlived the runner (hyperskill-plugin #67).
• Check the disk before and after the heavy step: df -h.

What to do

• Lower the memory peak: fewer parallel processes, or drop a step that grows without bound, as boost #1301 did for one job.
• Check out less: a sparse checkout of only what the job needs.

  - uses: actions/checkout@v7
    with:
      sparse-checkout: |
        src
        scripts

• On self-hosted runners: fewer runner pods per node or a memory limit on each, max-parallel: 1 for matrix jobs that each need most of a node, and stop build daemons (Gradle, the Kotlin compiler) before the tests run (hyperskill-plugin #67).
• Re-run: Re-run failed jobs, or gh run rerun <run-id> --failed. An automatic re-run should look at the annotation, not the log, since the log may be gone:

  gh api repos/OWNER/REPO/check-runs/JOB_ID/annotations --jq '.[].message' | grep -q "lost communication with the server"

• Be careful with automatic re-runs of deployments. omni #3517 re-runs at most twice, only when every failed job lost its runner and no newer release run exists, and never when a Terraform or Pulumi job died mid-run, since that can leave a state lock and a half-applied stack.

Telling it apart

• The runner was told to stop: the log ends with exit code 143 and "The runner has received a shutdown signal" (what to do).
• The job's time limit: the job ends as Cancelled with "The job has exceeded the maximum execution time" (what to do).
• No runner ever took the job: no runner and no steps ("The job was not acquired by Runner of type hosted").

See jobs that lost their runner from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so a failed job stands out next to the ones that passed, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "The runner has received a shutdown signal" · "The job has exceeded the maximum execution time" · Re-running jobs with debug logging · GitHub Actions plugins for IntelliJ IDEA compared · 日本語