"The runner has received a shutdown signal": the cause, and a runner with the memory to fix it

Your job died with "The runner has received a shutdown signal" and no exit code. On a GitHub-hosted runner the cause GitHub's maintainers confirmed is memory: ubuntu-latest has 8 GB on a private repository, and once it is gone the VM stops before any out-of-memory line reaches the log. Every retry burns minutes and blocks the merge.

Skipbox gives the job the memory it needs at a flat price: runs-on: skipbox for 16 GB at $39 a month, or skipbox-16x32 for 32 GB at $149, with unlimited minutes.

What the message means

The runner application logs it when its process is told to stop during a job: "The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled." The step then ends with "The operation was canceled." and no exit code, because none of your commands failed.

In actions/runner-images issue #15202, a GitHub maintainer reproduced it on an 8 GB ubuntu-24.04 runner: jobs under memory plus swap passed, jobs above it lost the runner with this exact message. A new image can trigger it with no change on your side, when a new default tool version needs more memory than the old one.

What it costs to stay at 8 GB

Each lost run is minutes billed for nothing, a re-run, and a pull request that can't merge. Working around it is work too:

• lowering test workers, make -j or Gradle's worker count, so the job runs slower
• capping Node's --max-old-space-size or the JVM's -Xmx
• splitting one job into several and wiring them back together
• pinning a tool version until someone finds time to fix it

The memory need only grows: bigger test suites, bigger builds, more jobs from coding agents pushing fixes. GitHub's answer is a larger runner, billed every minute:

GitHub's figures are on GitHub Team, after its included compute; larger runners need Team or Enterprise Cloud. Check your own minutes in the calculator on the home page.

A self-hosted runner of your own costs nothing on GitHub's bill, but it shows the same message whenever its service restarts, the host reboots for patches or an autoscaler pulls the machine. Running one well is servers, patching, cleanup and scaling.

Skipbox fixes it

The memory, at a flat price

Minutes are unlimited. Skipbox registers as a self-hosted runner, so its jobs use none of your GitHub minutes and don't stop at an Actions budget. Jobs beyond your plan's machines wait their turn.

Faster reruns

Each plan is a VM kept for your account. Docker images, layers and build cache, package caches and the tool cache stay on its disk, so the next run starts with them instead of downloading everything again.

A machine you don't babysit

Skipbox keeps the image updated, wipes each job's credentials, processes and containers (the checkout and Cargo's target/ stay from 13 November 2026), health-checks the machine after every job and rebuilds one that fails. The VMs run Ubuntu 24.04 with Docker, Node.js and Python.

Moving is one line

jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Sign in to Skipbox with GitHub.
2. Install the Skipbox GitHub App and pick the repositories.
3. Change runs-on and push.

skipbox runs on every plan, skipbox-16x32 on plan L. To move back, change the line back.

Try it on your own jobs

The trial is free for 7 days or 3,000 job-minutes, whichever comes first, with no card. It runs runs-on: skipbox jobs at 4 vCPU and 16 GB, 2× the memory of a private repository's ubuntu-latest, so move the job that runs out of memory and see it run with its caches kept, then take plan L for a job that needs more.

Updated November 11, 2026