colab cannot execute code, session busy after a reconnect

Not specified by the original author.

TL;DR

Reset the runtime state: disconnect, then restart or factory-reset the runtime to clear the stuck kernel. The frontend reconnected to a backend whose kernel is wedged, so execute requests queue behind a call that will never finish. Runtime menu: restart runtime first; if it stays busy, factory reset the runtime.

colab "cannot execute code, session busy" after a reconnect

Use this when

• After a reconnect, cells show session busy and never execute
• Interrupt does nothing and the kernel status stays busy for many minutes
• The problem survives a browser refresh but a new notebook works

Not for this skill when

• The session expired after 12 hours with variables lost - that is item 117
• The runtime dropped from GPU to CPU - that is item 119
• Drive will not mount - that is item 120

Steps

1. Confirm the wedge: wait 2 to 3 minutes and try interrupting execution. Expected: the interrupt has no effect and the status stays busy.

2. Try the gentle path: Runtime menu, Restart runtime. Expected: the kernel restarts and the status returns to idle.

3. Test execution with a trivial cell (for example 1+1). Expected: it runs immediately, proving the kernel is healthy.

4. If it is still busy, use the hard path: Runtime menu, Factory reset runtime. Expected: the VM is replaced; all local state is gone but the kernel is fresh.

5. Re-mount Drive and re-run setup cells, restoring from checkpoints rather than re-running the whole history. Expected: the notebook is productive again within minutes.

Tool compatibility

Google Colab

Variant phrasings

colab cannot execute code session busy

Same fix applies: see the Steps section above.

colab stuck session busy after reconnect

Same fix applies: see the Steps section above.

colab kernel busy forever reconnect

Same fix applies: see the Steps section above.

Why it happens

Colab splits the UI session from the backend kernel session. A network drop can leave the backend kernel stuck inside a blocking call (a hung download, a deadlocked C extension) while the UI happily reconnects to the same wedged backend. Execute requests then pile up behind the stuck call and the UI reports busy forever. Restarting the runtime kills the kernel process; factory reset replaces the whole VM when the restart path itself is wedged.

Edge cases / pitfalls

• Factory reset destroys /content; anything not on Drive is gone - checkpoint first as a habit.
• A cell that wedges the kernel deterministically (infinite loop, blocking input) will re-wedge the fresh runtime; fix the cell.
• Browser extensions that block websockets can mimic this; test in a clean profile if resets do not help.

Provenance

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

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

Thread query: colab "cannot execute code, session busy" after a reconnect

TL;DR: Reset the runtime state: disconnect, then restart or factory-reset the runtime to clear the stuck kernel. The frontend reconnected to a backend whose kernel is wedged, so execute requests queue behind a call that will never finish. Runtime menu: restart runtime first; if it stays busy, factory reset the runtime.

Not specified by the original author.

TL;DR

Verify the accelerator with nvidia-smi, then re-request a GPU runtime from the Runtime menu. Colab assigns GPUs on availability; when none are free it silently gives a CPU runtime and your code slows down without erroring. Check the hardware at the start of every session and fail fast if the GPU is missing.

colab GPU runtime unavailable: silently fell back to CPU

Use this when

• Training is suddenly much slower and nvidia-smi reports no devices
• The Runtime menu shows the accelerator set to GPU but torch reports cpu
• GPU worked yesterday on the same notebook and now does not

Not for this skill when

• The session expired at 12 hours - that is item 117
• Cells will not execute at all - that is item 118
• You need more RAM rather than a GPU - that is a high-RAM runtime question

Steps

1. Check what you actually got: run nvidia-smi in a cell. Expected: either a GPU listed or a no-devices message - trust this, not the menu label.

2. Confirm from the framework: print the device the framework sees (for example the torch cuda availability flag). Expected: agreement with nvidia-smi.

3. Re-request the accelerator: Runtime menu, Change runtime type, set Hardware accelerator to GPU, save. Expected: the runtime restarts with a GPU attached when capacity allows.

4. Add a fail-fast cell at the top of GPU notebooks that raises if no GPU is present. Expected: future silent fallbacks become loud immediate errors.

5. If GPUs are consistently unavailable, schedule heavy runs at off-peak hours or consider a paid tier. Expected: higher GPU assignment rates.

Tool compatibility

Google Colab, NVIDIA drivers via nvidia-smi, PyTorch / TensorFlow / JAX

Variant phrasings

colab GPU unavailable fell back to CPU

Same fix applies: see the Steps section above.

colab no GPU assigned silently CPU

Same fix applies: see the Steps section above.

colab runtime type GPU but no cuda device

Same fix applies: see the Steps section above.

Why it happens

Colab's free GPU pool is shared and finite. When you request a GPU runtime and none is available, the backend provisions a CPU runtime instead of queueing, and nothing in the UI screams about it - the menu can even still suggest GPU was requested. Code written device-agnostically then runs on CPU, often 10 to 50 times slower, with no error. The only reliable signal is asking the machine itself via nvidia-smi at session start.

Edge cases / pitfalls

• The menu setting persists per notebook; a stale CPU setting survives across sessions until changed.
• Some GPU types are scarcer than others; requesting a specific one can fail more often than accepting any.
• Fail-fast cells save hours of slow training discovered too late.

Provenance

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

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

Thread query: colab GPU runtime unavailable: silently fell back to CPU

TL;DR: Verify the accelerator with nvidia-smi, then re-request a GPU runtime from the Runtime menu. Colab assigns GPUs on availability; when none are free it silently gives a CPU runtime and your code slows down without erroring. Check the hardware at the start of every session and fail fast if the GPU is missing.

Not specified by the original author.

TL;DR

Checkpoint to Drive early and often, then resume from the latest checkpoint in a fresh runtime. Colab recycles runtimes after roughly 12 hours with no way to extend a single session; the only defense is durable checkpoints. Save model weights and optimizer state to Drive every epoch, and make the notebook resume automatically if checkpoints exist.

colab runtime disconnected: 12-hour session expired mid-training

Use this when

• The runtime disconnects near the 12-hour mark with all variables lost
• Training was at epoch 40 of 100 when the session died
• You need multi-day training but only have Colab runtimes

Not for this skill when

• The session says busy after a reconnect - that is item 118
• The runtime silently switched from GPU to CPU - that is item 119
• Drive fails to mount at all - that is item 120

Steps

1. Mount Drive at the start of the notebook and choose a checkpoint directory. Expected: the drive mount succeeds and the directory is writable.

2. Add checkpointing to the training loop: save model and optimizer state every epoch (or every N steps) to the Drive directory, keeping the last few. Expected: checkpoint files appear in Drive during the run.

3. Write the resume logic first: on startup, list the checkpoint directory and load the latest checkpoint if one exists, skipping already-done epochs. Expected: a fresh runtime continues from the last epoch instead of epoch zero.

4. Test the resume path deliberately: restart the runtime mid-training and re-run. Expected: training resumes from the checkpoint without manual intervention.

5. For runs longer than 12 hours total, plan the checkpoint cadence so at most one epoch of work is ever at risk. Expected: the worst-case loss after a recycle is bounded and known.

Tool compatibility

Google Colab, PyTorch / TensorFlow / JAX, Google Drive

Variant phrasings

colab 12 hour session expired training lost

Same fix applies: see the Steps section above.

colab runtime disconnected mid training resume

Same fix applies: see the Steps section above.

colab session timeout checkpoint to drive

Same fix applies: see the Steps section above.

Why it happens

Colab runtimes are ephemeral by design: the backend reclaims the VM after about 12 hours regardless of activity, and the local disk (including /content) is discarded with it. Only files written to mounted Drive survive. Training loops that keep state only in RAM therefore lose everything at recycle time. Checkpointing to Drive converts the 12-hour limit from a catastrophe into a scheduled restart, and resume logic makes the restart automatic.

Edge cases / pitfalls

• Drive write throughput is limited; checkpointing every step can bottleneck training - checkpoint per epoch.
• Keep checkpoints small enough that the save itself finishes well before any timeout.
• Paid Colab tiers raise but do not remove the session limit; the checkpoint habit still applies.

Provenance

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

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

Thread query: colab runtime disconnected: 12-hour session expired mid-training

TL;DR: Checkpoint to Drive early and often, then resume from the latest checkpoint in a fresh runtime. Colab recycles runtimes after roughly 12 hours with no way to extend a single session; the only defense is durable checkpoints. Save model weights and optimizer state to Drive every epoch, and make the notebook resume automatically if checkpoints exist.