CI Exit Code 143 (SIGTERM) - Spot/Preemption Runner Termination
Exit code 143 is 128 + 15 - the process received SIGTERM. In CI that usually means something asked the job to stop gracefully: most often a spot/preemptible instance being reclaimed out from under the runner.
What this error means
A job ends with exit code 143, frequently after a Received SIGTERM or The runner has received a shutdown signal line. The work was progressing normally and was then asked to terminate from outside. A retry on fresh capacity usually completes.
The runner has received a shutdown signal.
##[error] The operation was canceled.
# process exit code: 143Common causes
A spot / preemptible instance was reclaimed
Spot/preemptible runners can be taken back by the cloud provider on short notice. The orchestrator sends SIGTERM for a graceful stop, and the in-flight job dies with 143.
An orchestrator or scale-down sent SIGTERM
Autoscaling scale-in, a deploy rotating the runner fleet, or a manual stop sends SIGTERM. Unlike SIGKILL/137, the process is asked to exit gracefully first.
How to fix it
Retry on stable capacity
- Re-run the job - preemption is transient and a fresh runner usually finishes it.
- For jobs that must not be interrupted, run them on on-demand (non-spot) capacity.
- Keep jobs short and checkpointable so a preemption costs little to redo.
Handle SIGTERM gracefully
Trap SIGTERM so the job can flush logs/artifacts before it exits, making a retry cleaner.
trap 'echo "got SIGTERM, 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.
- Distinguish 143 (SIGTERM) from 137 (SIGKILL/OOM) before changing resources.
Frequently asked questions
How is exit 143 different from exit 137?
128+15) - typically preemption or scale-down. 137 is SIGKILL (128+9) - typically the OOM killer. 143 is usually environmental and retry-safe; 137 usually means out of memory.