SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
CI/CD New Added 8 September 2026

GitHub Actions: The runner has received a shutdown signal

The job died with the machine under it rather than failing. On hosted runners it usually means the process exhausted memory or disk and the host reclaimed it; on self hosted runners it means a spot instance was reclaimed or the autoscaler removed the node mid job.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Watch the resources the job is actually using
- run: |
    free -h; df -h
    /usr/bin/time -v ./build.sh

# Free disk on hosted runners before a large build
- run: |
    sudo rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc
    docker system prune -af

# Cap memory hungry tools rather than letting the kernel choose
NODE_OPTIONS: --max-old-space-size=6144

# Self hosted: run on demand instances, or drain before scale in

How to diagnose CI/CD errors

CI failures that do not reproduce locally are almost always about environment, permissions or resource limits rather than about your code. CI runners have less memory than a laptop, a deliberately restricted token, a clean cache, and often a different CPU architecture. Treating a CI failure as a code bug before checking those four things wastes an enormous amount of time.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Re-run the job with debug logging enabled (ACTIONS_STEP_DEBUG=true in GitHub Actions, CI_DEBUG_TRACE in GitLab). The default log deliberately hides the most useful lines.
  2. Print the environment early: env | sort, node -v, free -m, df -h. Half of all "works on my machine" CI bugs are visible in that output.
  3. Check token permissions explicitly. GitHub's GITHUB_TOKEN defaults to read-only in many organisations and produces the misleading Resource not accessible by integration error.
  4. Remember that secrets are not available to workflows triggered by pull requests from forks. This is a security feature, not a misconfiguration.
  5. Reproduce locally in the same container image the runner uses, rather than on your host, before changing pipeline configuration.

Tools worth reaching for

  • ACTIONS_STEP_DEBUG
  • act (local Actions runner)
  • docker run <runner image>
  • free -m / df -h in-job

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.github.com

Related CI/CD errors

See all 18 CI/CD errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.