GitHub Actions runner connection lost mid-step

By Kaveh Alemi·Latchkey

If the runner loses its connection to the GitHub Actions service mid-step, the job is failed or retried. This is usually a transient network/instance event rather than a workflow bug.

What this error means

A job fails midway with a message about lost communication with the server, often on a long or resource-heavy step.

Error: The operation was canceled.
The runner has lost communication with the server.

Common causes

Transient network interruption

A brief loss of connectivity between the runner and the service cancels the job.

Runner instance terminated under it

A self-hosted instance or spot reclaim can cut the connection mid-step.

How to fix it

Make steps resumable and retryable

1. Break long jobs into smaller, restartable steps.
2. Add idempotent retries around network-heavy operations.
3. On self-hosted/spot capacity, ensure jobs can be safely re-run.

- name: Re-runnable fetch
  run: |
    for i in 1 2 3; do
      curl -fsSL https://example.com/big.tar && break
      sleep 5
    done

How to prevent it

• Design jobs to be idempotent so a re-run is safe.
• On Latchkey managed runners, a runner that drops its server connection mid-step is treated as a transient failure and the job is auto-retried on a fresh runner from the warm pool, instead of failing the build.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions