CI Job "Killed" with No Error - Silent OOM SIGKILL
By Kaveh Alemi·Latchkey
A bare Killed with no traceback is the signature of SIGKILL - the kernel terminated the process so abruptly it never got to print why. On a runner, that almost always means out of memory.
What this error means
The log shows a single line Killed (sometimes Killed (program ...)) and the step fails. The application produced no error, no stack trace, and no exception - the process was simply stopped mid-execution.
CI log
npm run test
Killed
##[error] The process '/usr/bin/bash' failed with exit code 137
Common causes
The OOM killer sent SIGKILL
When memory pressure crosses the limit, the kernel picks a victim by OOM score and kills it with signal 9. SIGKILL is uncatchable, so the process cannot log anything before it dies.
A wrapper or watchdog hard-killed the process
A timeout --signal=KILL, a supervisor, or a parent script may SIGKILL a child. The symptom is identical to an OOM kill - bare Killed with no diagnostics.
How to fix it
Confirm the OOM kill in the kernel log
The kernel records every OOM kill. Find it to confirm memory was the cause and which process was chosen.
Terminal
dmesg -T | grep -i -E 'killed process|oom-killer|out of memory'
# or
journalctl -k | grep -i oom
Reduce memory pressure or add headroom
Move the job to a runner with more RAM.
Lower concurrency in the killed step (fewer workers, smaller batch sizes).
If a watchdog killed it, raise the watchdog limit rather than treating it as OOM.
How to prevent it
Right-size runners and cap language heaps below the limit.
Log memory high-water marks so you see growth before it kills the job.
Distinguish OOM kills from watchdog kills before changing resources.
Frequently asked questions
What causes ""Killed" (no stack trace)"?
When memory pressure crosses the limit, the kernel picks a victim by OOM score and kills it with signal 9. SIGKILL is uncatchable, so the process cannot log anything before it dies.
How do I fix "Killed" (no stack trace)?
The kernel records every OOM kill. Find it to confirm memory was the cause and which process was chosen.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.
