Google Colab time limits: why your runtime disconnects and how to survive it

The limits Google actually publishes

If your Colab runtime just died mid-training, you hit one of two walls: the session cap or the idle cutoff. Google's documentation is upfront about the general rules, even if it's light on exact numbers. As the Colab FAQ puts it, "Colab prioritizes interactive compute. Runtimes will time out if you are idle."

On the free tier, notebooks "can run for at most 12 hours, depending on availability and your usage patterns." That 12-hour figure is a ceiling, not a promise.

Free runtimes are built for interactive use: they time out when you stop interacting, and Google deletes idle VMs after a while. Google also bars free runtimes from SSH shells, remote desktops and distributed computing workers.

Paid plans get "increased compute availability based on your compute unit balance". Colab Pro ($9.99 a month for 100 compute units) adds "extended execution times and saving of output to Drive based on availability", and Colab Pro+ ($49.99 a month for 600 units) adds background execution. If your units run out on a paid plan, Google says to "expect to experience backend termination", and you drop back to free-tier limits.

What Google does not publish

Search for Colab disconnect rules and you'll find posts quoting exact idle minutes or daily GPU quotas. None of those numbers come from Google.

The FAQ says plainly that "Colab does not publish these limits, in part because they can vary over time." Free GPU access is "heavily restricted" and the GPU types "vary over time". What worked for someone last month isn't a rule you can plan a training run around, because the caps move with demand and with how much you've used the service.

Google's one concrete tip: close Colab tabs when you're done, and avoid GPUs or extra memory when your work doesn't need them. That makes it "less likely that you will run into usage limits".

Colab limits by plan, next to Kaggle

If you're deciding between paying for compute units and moving your notebook to Kaggle, here is how the tiers line up on paper.

Kaggle's weekly GPU quota is 30 hours "or sometimes higher depending on demand and resources". You also get 20 GB of saved output in /kaggle/working, and "Save & Run All" runs the whole notebook in a new session, as long as it finishes within 12 hours. Kaggle's notebook docs give the idle limit while editing as 20 minutes, but its GPU tips page mentions 60, so don't plan around either.

Survive a disconnect: checkpoint to Google Drive and resume

When Colab deletes your VM, its local disk goes with it. Everything you wrote to /content is gone, so a disconnect at hour 11 wipes out the whole run unless your checkpoints live somewhere else.

The fix is to mount Google Drive, save a checkpoint there every N steps, and have the training loop look for that checkpoint before it starts from scratch. Writing to a temporary file first and renaming it means a disconnect in the middle of a save can't leave you with a broken checkpoint.

import os

import torch
from google.colab import drive
from tqdm import tqdm

drive.mount("/content/drive")
CKPT = "/content/drive/MyDrive/checkpoints/run1.pt"
os.makedirs(os.path.dirname(CKPT), exist_ok=True)

start_step = 0
if os.path.exists(CKPT):
    state = torch.load(CKPT, map_location="cpu")
    model.load_state_dict(state["model"])
    optimizer.load_state_dict(state["optimizer"])
    start_step = state["step"] + 1

for step in tqdm(range(start_step, total_steps), initial=start_step, total=total_steps):
    train_step()
    if step % 500 == 0:
        state = {"model": model.state_dict(), "optimizer": optimizer.state_dict(), "step": step}
        torch.save(state, CKPT + ".tmp")
        os.replace(CKPT + ".tmp", CKPT)

After a disconnect, reconnect, run the cells again and the bar picks up where the last checkpoint left off. Save often enough that losing one interval doesn't hurt, but not so often that writing to Drive slows training.

What Pro+ background execution changes, and what it doesn't

Colab Pro+ lets you close the browser and keep training for up to 24 hours, as long as you have a positive compute unit balance. Your output is saved to Drive after each cell finishes.

What it doesn't give you is a machine that waits around while nothing runs. Google is explicit that "Idle timeouts only apply if code execution terminates." Once your training cell finishes, or a cell errors out, the idle clock starts and the VM is deleted. Even on Pro+, "Colab resources are not guaranteed and not unlimited, and usage limits sometimes fluctuate."

Get a ping when the runtime dies

Checkpoints save your weights, but you still lose hours if a run dies at midnight and you only notice the next morning. A try/except block or a message at the bottom of the notebook can't help: when Colab deletes the VM, your Python process dies with it, and in a notebook an ordinary exception doesn't end the process either. The only thing that catches a dead runtime is an outside alert that fires when progress stops.

Use the drop-in tqdm from tqdm_live in notebooks, because the notebook widget bar is not streamed; it takes the same initial and total arguments. Keep the stall window at 30 minutes or less, and a little longer than your slowest checkpoint save.