GitHub Actions "The runner has received a shutdown signal"
The runner process got an OS-level shutdown signal while a job was running, usually because the underlying host was terminated, scaled down, or preempted, so the job cannot finish.
What this error means
A running job stops abruptly with "The runner has received a shutdown signal. This indicates the runner service is shutting down." Steps after that point never execute and the job is marked failed.
The runner has received a shutdown signal. This indicates the runner service is shutting down, and so this job is being canceled.Common causes
Spot / preemptible host reclaimed
A spot or preemptible VM running the self-hosted runner was reclaimed by the cloud provider, sending the runner a shutdown signal mid-job.
Autoscaler scaled the host down
A scale-down policy or idle-timeout terminated the host while it was still executing a job.
How to fix it
Protect in-flight jobs from termination
- Make scale-down skip hosts that are currently running a job.
- Use ephemeral runners so a host is only reclaimed between jobs.
- For spot capacity, drain on the interruption notice rather than mid-job.
- Re-run the affected job once stable capacity is available.
Run on auto-retrying managed capacity
Latchkey managed runners auto-retry transient infrastructure failures like a reclaimed host and use warm, right-sized capacity, so a single preemption does not surface as a hard job failure.
How to prevent it
- Never scale down a host with an active job.
- Prefer ephemeral, one-job runners on volatile capacity.
- Honor spot interruption notices to drain gracefully.