Diagnosing Google Colab Runtime Disconnects and Lost Session State

Recognizable Condition

A Colab notebook that stops responding mid-computation is a common failure mode, but the fix depends on whether the runtime is being throttled by idle limits, starved of memory or disk, or simply losing its ephemeral container. The useful takeaway: before restarting blindly, run a short ordered check that separates session lifecycle issues from resource exhaustion and persistence gaps.

You are likely in this situation if:

• A cell hangs indefinitely after the browser tab has been backgrounded.
• The toolbar shows Runtime disconnected or Cannot connect to GPU/TPU backend.
• New executions fail until the runtime is reconnected or restarted.
• After a restart, previously installed packages or files under /content are gone.

Cause and Diagnostic Table

Symptom or Pattern	Likely Cause	Quick Diagnostic
Disconnect follows a period of inactivity	Session lifecycle: idle timeout or maximum runtime lifetime	Note elapsed time since the last cell execution; check Runtime > View resources for session age if shown
Hang or crash during heavy allocation	Resource exhaustion: RAM or GPU OOM, disk full under /content	Run !free -h and !df -h /content; check Runtime > View resources
Files or packages missing after restart	Environment loss: /content and installed packages are ephemeral	List /content after restart; compare with a Drive-mounted path
GPU/TPU assigned but unusable, or assignment fails	Backend availability or quota	Check Runtime > Change runtime type; compare with a CPU-only runtime

Ordered Checks

Run these steps in order. Each one either isolates the cause or narrows the remaining possibilities.

1. Confirm runtime type and connection. Open Runtime > Change runtime type and Runtime > View resources. Record whether the accelerator is None, GPU, or TPU, and note the RAM and disk figures shown.
2. Keep the browser tab visible and retry a small cell. Create a new cell with print('alive') or a timestamp and run it. If it executes immediately, the backend is reachable; if it hangs, the runtime is likely disconnected.
3. Restart the runtime and rerun only setup cells. Use Runtime > Restart runtime, then execute only your installation and import cells. If the disconnect recurs immediately with a trivial workload, the issue is not your computation.
4. Reproduce with a minimal workload and smaller batch. Replace your data pipeline with a controlled allocation—for example, a NumPy array sized to a fraction of available RAM—and reduce batch size. If the hang disappears, the original workload exceeded a resource limit.
5. Measure memory and disk before and after. In a code cell, run the shell commands !free -h and !df -h /content. These require no special permissions and report the container view, not the full platform quota, but a sharp rise before a hang is a strong signal. If psutil is installed, you can also sample psutil.virtual_memory() from Python.
6. Test with Drive-mounted persistence. Mount Google Drive using the standard pattern in a code cell:

   from google.colab import drive
   drive.mount('/content/drive')

   Then write a checkpoint file under /content/drive/MyDrive/ and verify it appears in the Drive web UI. Expected check: the file is visible in Drive after the cell completes. Relevant risk: authentication prompts and added I/O latency can make heavy operations look like a hang.
7. Compare CPU-only versus GPU/TPU runtime. Switch to a CPU-only runtime and rerun the minimal notebook. If the disconnect is GPU-specific, the problem is likely backend availability or GPU memory, not general session health.

Fixes Tied to Findings

• Idle or lifetime disconnects: Reconnect or restart the runtime, then persist artifacts to Google Drive or cloud storage rather than relying on /content. Re-run setup cells to restore packages.
• OOM (out of memory): Reduce batch size, delete large objects with del, and call gc.collect(). Avoid loading entire datasets into RAM; stream or shard them instead.
• Disk pressure: Remove temporary files from /content, write intermediate outputs to Drive or cloud storage, and prefer streaming over local downloads.
• Missing packages after restart: Put all !pip install commands in a dedicated setup cell at the top of the notebook so the environment can be rebuilt deterministically.
• GPU unavailability: Fall back to a CPU runtime for debugging, or retry the GPU assignment later. Do not assume a GPU backend will be available on demand.

Minimal Reproduction Notebook

A two-cell notebook helps separate browser behavior from platform limits. In the first cell, print a timestamp and runtime details:

import sys, platform, datetime
print(datetime.datetime.utcnow().isoformat())
print('Python:', sys.version)
print('Platform:', platform.platform())

In the second cell, allocate a controlled array. Adjust the size to a value you expect to fit comfortably in RAM:

import numpy as np
# Placeholder: start with a small size, e.g. 1_000_000 float64 elements (~8 MB)
a = np.ones(1_000_000, dtype=np.float64)
print('Allocated:', a.nbytes / 1e6, 'MB')

Run the notebook with the tab foregrounded, then repeat with the tab backgrounded for a fixed interval (for example, 10–15 minutes). Record when execution stops. Expected checks: the timestamp cell should return immediately when the runtime is healthy; the allocation cell should either complete or trigger a visible error if memory is exhausted. Do not assume a specific timeout value—verify current behavior in the Colab UI.

Escalation Criteria

Escalate to Colab support or your platform administrator when:

• The same account and network produce immediate repeated disconnects on a fresh runtime with a trivial workload.
• Resource panels show quota exhausted despite no local misuse (no large downloads, no long idle periods).
• Google Drive mounting fails with authentication errors that persist after re-authorizing.
• Behavior differs across browsers or devices in a way that suggests a platform-side backend issue rather than a local one.

Before reporting, capture:

• Runtime type (CPU, GPU, TPU) and any accelerator details.
• Timestamps of the disconnect relative to cell execution.
• A resource snapshot from !free -h, !df -h /content, and Runtime > View resources.
• The minimal repro notebook described above.

Limitations and Verification

• Exact idle timeout, maximum session lifetime, GPU/TPU availability, and Pro usage limits are time- and region-sensitive and can change. Verify them in the current Colab UI rather than relying on remembered values.
• Colab is not a durable server: /content and installed packages may disappear after a restart, so treat them as ephemeral.
• Mounted Google Drive can add latency and authentication prompts; heavy I/O may look like a hang rather than a disconnect.
• Shell commands such as df and free report the container view, not the full platform quota; high usage can precede a crash without showing a hard limit.
• If using Colab Enterprise or Vertex AI-backed environments, quotas, persistence, runtime behavior, and support channels can differ from standard consumer Colab.

Practical verification: After any restart, run !df -h /content and list the directory contents to confirm which files survived. Compare that with a Drive-mounted path. If artifacts you expected are missing from /content but present in Drive, your persistence strategy is working as intended.