GitHub Actions "The runner has received a shutdown signal" in CI
The runner process was told to shut down while a job was in flight. Something outside the job - a preemption, an autoscaler scale-down, or host maintenance - asked the runner to stop, so the job was cut off.
What this error means
A job ends with The runner has received a shutdown signal, often alongside The operation was canceled and an exit code of 143 (SIGTERM). The work was progressing normally and was stopped from outside. A retry on fresh capacity completes it.
The runner has received a shutdown signal. This indicates the runner
service or host machine is being stopped.
##[error] The operation was canceled.Common causes
The host was preempted or scaled down
A spot/preemptible instance reclaim, or an autoscaler removing idle-looking capacity, sends the runner a shutdown signal mid-job. It is an infrastructure event, not a build failure.
Maintenance or a fleet rotation
A deploy rotating the runner fleet, or planned host maintenance, stops the runner service gracefully, ending the in-flight job.
How to fix it
Retry on stable capacity
- Re-run the job - a shutdown signal is transient and a fresh runner usually finishes it.
- For jobs that must not be interrupted, use on-demand (non-preemptible) capacity.
- Keep jobs short and checkpointable so a mid-job stop costs little to redo.
Handle the signal gracefully
Trap SIGTERM so the job flushes logs/artifacts before exiting, making the retry cleaner.
trap 'echo "shutdown signal received; cleaning up"; cleanup; exit 143' TERMHow to prevent it
- Use on-demand capacity for jobs that cannot tolerate preemption.
- Make jobs idempotent and checkpointable so retries are cheap.
- Schedule fleet rotations/maintenance to avoid interrupting long jobs.