GitHub Actions: "The runner has received a shutdown signal"
The machine running the job was told to stop, so it stopped the step that was running and gave up the job. Your step did not fail on its own. On GitHub-hosted runners this usually comes with memory running out; on self-hosted runners, with the runner service being stopped or restarted.
What it looks like
The last lines of the log, from a public job on November 2, 2026 (runs-on: ubuntu-latest):
##[error]Process completed with exit code 143. ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
- The job fails. Its annotation may say only "Process completed with exit code 143." or "The operation was canceled.", which a timeout can also produce, so look for the shutdown line in the log (chdb-core #309).
- Exit code 143 is 128 + 15: the step's process was ended with SIGTERM.
- The steps after it do not run, not even
if: always()ones: in that job, a summary step withif: always()and the post steps were skipped (funcd #1362). Anything you want to keep has to be written during the step. - The output often just stops, with no failing test. In one project every test had passed and the runner died in the half second before the result line (brighterscript-game-engine #429).
On GitHub-hosted runners: usually memory
A standard Linux or Windows runner has 16 GB of memory in a public repository and 8 GB in a private one; ubuntu-slim has 5 GB, and the arm64 macOS runners 7 GB (GitHub's runner reference, November 3, 2026). Reports from late October and November 2026:
- One project sampled memory every 30 seconds: available memory fell from 14,163 MB to about 2,300 MB, the 3 GB of swap filled, one test binary reached 11 GB, and the runner received the shutdown signal 19 seconds after the last sample. The kernel log showed no out-of-memory kill. The cause was tests that never shut down what they built (funcd #1362).
- Another found that 14 of 23 failed test shards since November 1 ended this way, 10 to 13 minutes in, where two compiler processes of about 9 to 11 GB each overlapped on a 16 GB runner (ripr-swarm #12703).
- A third traced it to a
-racetest binary of about 14 GB on a 16 GB runner (conduit #3311). - Some projects describe a hosted runner being preempted mid-job, and retry those runs (campus-erp #49).
The same overload can instead end with "The hosted runner lost communication with the server", and then the log can be lost too (funcd #1362).
On self-hosted runners: the runner service stopped
The message names it: the runner service was stopped, or a runner started by hand (./run.sh) was cancelled. Anything that stops or restarts the service in the middle of a job does the same. In chdb-core #309, unattended upgrades ran on the runner machines at 06:00 UTC and restarted the runner service, which killed the builds running then: all four builds of one pull request between 06:04 and 06:22 UTC, and three of the four builds of one nightly. The fix belongs on the machine: ephemeral runners, or no restarts while jobs can run.
What to do
- Measure memory during the step, so the numbers reach the log before the runner stops:
- name: Test run: | (while true; do echo "mem $(date -u +%T) $(free -m | awk 'NR==2 {print $7}') MB available"; sleep 30; done) & sampler=$! trap 'kill $sampler' EXIT make test - Lower the peak: build or test the memory-heavy packages one at a time (ripr-swarm, conduit), fewer parallel compilers or test processes (
cargo build -j 2,go test -p 1), or split the job into more shards. - Look for memory that tests never give back: in funcd #1362, eight tests never shut down what they built, and the live memory grew by about 1.8 GB on each of the five passes of
-count=5. - Use a runner with more memory: a larger runner (paid, on GitHub Team or Enterprise Cloud), or a self-hosted one.
- Re-run: Re-run failed jobs, or
gh run rerun <run-id> --failed. GitHub Actions has no retry setting for a lost runner, so some projects re-run automatically, only when every failed job's log has the shutdown line and only on the first attempt (campus-erp #49, chdb-core #309). A sketch, in a workflow on the default branch:
on:
workflow_run:
workflows: [CI]
types: [completed]
permissions:
actions: write
jobs:
rerun:
if: github.event.workflow_run.conclusion == 'failure' && github.event.workflow_run.run_attempt == 1
runs-on: ubuntu-latest
steps:
- env:
GH_TOKEN: ${{ github.token }}
REPO: ${{ github.repository }}
RUN: ${{ github.event.workflow_run.id }}
run: |
for id in $(gh api "repos/$REPO/actions/runs/$RUN/jobs?per_page=100" --jq '.jobs[] | select(.conclusion == "failure") | .id'); do
gh api "repos/$REPO/actions/jobs/$id/logs" > job.log || exit 0
grep -q "The runner has received a shutdown signal" job.log || exit 0
done
gh run rerun "$RUN" --failed --repo "$REPO"
Telling it apart
- 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 steps at all ("The job was not acquired by Runner of type hosted").
- The account's billing: the job fails within seconds with no steps ("recent account payments have failed").
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 job has exceeded the maximum execution time" · "The job was not acquired by Runner of type hosted" · Re-running jobs with debug logging · GitHub Actions plugins for IntelliJ IDEA compared · 日本語