Diagnosing Google Colab Kernel Disconnects and Out-of-Memory Errors
Diagnose Colab kernel disconnects and CUDA out-of-memory errors using the Session pane, runtime type settings, and memory checks.
25 Mar 2026, 11:02 UTC

Recognize the condition
A Google Colab notebook can stop executing without warning. A cell that was training a model suddenly halts, the runtime indicator in the top-right corner reads "Disconnected," or Python raises "RuntimeError: CUDA out of memory." These interruptions are usually diagnosable from the Colab interface itself, and most have a concrete fix that does not require contacting support.
The "runtime" is the virtual machine that executes your notebook cells. "OOM" means out of memory: the GPU or system RAM has no space left for the current workload. "Batch size" is the number of samples processed before model weights are updated.
| Symptom | Likely cause | First check |
|---|---|---|
| Cell execution stops and the top-right shows "Disconnected" | Network blip, idle timeout, or runtime preemption | Session pane status and a test cell |
| "RuntimeError: CUDA out of memory" | GPU memory exhausted by model, batch size, or cached variables | !nvidia-smi output |
| "MemoryError" or very slow CPU training | System RAM exhausted | !free -m output |
| Cells run but GPU utilization stays near zero | Wrong runtime type, such as CPU selected for a GPU workload | Runtime > Change runtime type |
Ordered diagnostic checks
- Confirm the connection state. Look at the indicator in the top-right corner. Run a minimal cell such as
print("alive"). If the cell never finishes or the runtime says "Disconnected," the VM is not executing code. - Verify the runtime type matches the workload. Open Runtime > Change runtime type. GPU workloads need a GPU runtime; CPU-only workloads do not benefit from a GPU and may waste quota. A mismatch causes silent performance degradation rather than an immediate error.
- Inspect GPU memory. Run
!nvidia-smiin a code cell. No administrator permissions are required. The command reports used and total GPU memory. If the runtime has no GPU attached, the command returns an error. - Inspect CPU memory. Run
!free -min a code cell. This shows available system memory in megabytes. Consistently low free memory suggests the notebook is too large for the selected runtime. - Check for idle or preemption signs. Colab may terminate idle virtual machines after a period of inactivity, and free-tier runtimes can be preempted to reclaim capacity. Long-running cells with no output are especially vulnerable.
Fixes tied to findings
If the runtime shows "Disconnected"
Save your work before restarting. Use File > Save a copy in Drive so the notebook and any saved outputs persist outside the ephemeral VM. Then select Runtime > Restart session. After the runtime returns, run print("alive") again. Restarting clears in-memory variables that were not saved to disk or Drive.
If you see "CUDA out of memory"
- Reduce the batch size in your training loop. Smaller batches use less GPU memory per step.
- Clear cached variables with
%reset -f. This IPython magic deletes all variables in the current session. Risk: it irreversibly removes dataframes, models, and counters; save anything you need first. - Switch to a runtime with more memory if one is available, or move parts of the workload to CPU.
If the wrong runtime type is selected
Open Runtime > Change runtime type and choose the type that matches your code. A GPU runtime is required for CUDA operations; selecting CPU when the code calls .cuda() will raise a device error, while selecting GPU for pure NumPy work provides no speed benefit.
When to escalate
Escalate to Google Colab support if errors persist after a restart and configuration changes, if you lose notebook data that was not saved to Drive, or if the runtime is repeatedly preempted despite active use. Include the symptom, runtime type, and the output of !nvidia-smi or !free -m when you contact support.
Verify the result
After applying a fix, run print("test") and leave the notebook open for at least five minutes. Confirm the runtime stays connected and the Session pane shows no new OOM warnings. If the test cell completes and memory remains stable, the issue is likely resolved.
Limitations
Colab virtual machines are ephemeral: they are recycled when the session ends, and unsaved state is lost. Free-tier usage is subject to quotas and preemption that can change without notice. This guide covers common, well-established behaviors, but Colab’s platform limits and timeout policies are not guaranteed to remain fixed.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.