## TL;DR
Random periodic kernel deaths are the system killing the process, not your code raising: the OOM killer, a container memory limit, or an idle-culler with an aggressive timeout. Plot the kernel's memory over time and note the exact death times. If deaths coincide with memory peaks, it is OOM; if they coincide with idle periods, it is a culler; if neither, check dmesg for hardware or segfault patterns.

```text
jupyter kernel keeps dying randomly every few minutes, how to fix
```

## Use this when
- The kernel dies at irregular intervals with no cell running.
- Deaths happen even in an idle notebook.
- The pattern started after moving to a container, VM, or shared host.

## Not for this skill when
- Deaths happen on one specific cell. That cell is the cause.
- The kernel dies exactly on a schedule. That is a culler or cron, not random.

## Steps
1. Record exact death times over an hour. Verify: you have timestamps, not vibes.
2. Check for the OOM killer: `dmesg | grep -i "oom\|killed process"` (or the container runtime log). Verify: whether the kernel PID was OOM-killed.
3. Check for an idle culler: look at server config for cull settings and compare death times against idle periods. Verify: deaths follow idleness, not load.
4. Watch memory live: run a cell that prints `psutil` RSS every 30 seconds into a file. Verify: you see the growth curve before each death.
5. Fix the matching cause: raise the memory limit, disable or lengthen the culler, or fix the leaking code the graph reveals. Verify: an hour passes with no death.

## Variant phrasings
### jupyter kernel dies randomly
Short form. OOM vs culler vs hardware.

### kernel keeps dying idle notebook
The idle variant. Cull settings are the suspect.

### intermittent kernel death jupyter
General phrasing. Correlate times with logs.

Compatibility: ipykernel 6.x on Linux containers/VMs. dmesg access needs host or privileged container visibility.

## Why it happens
Kernels rarely die truly randomly; the randomness is in when a threshold is crossed. Memory leaks grow until the OOM killer fires at whatever moment the limit is hit, and idle cullers fire on wall-clock timers that feel random to the user. Without timestamps and a memory curve, every theory looks equally plausible, which is why this symptom generates so much guessing.

## Edge cases / pitfalls
- Restarting the kernel resets the memory curve and destroys the evidence. Measure first, restart second.
- The OOM killer may kill a sibling process (like the server) instead of the kernel. Check which PID died.
- Swap being disabled makes OOM kills sudden with no slowdown warning. The graph will show a cliff, not a slope.
- Do not raise the memory limit as the only fix when the graph shows a leak. You are just delaying the same death.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fF1EsKMRe_cLq1yKiA6vIw