Why can a paid Colab runtime end before 24 hours? What an L4 user report can establish

The FAQ describes Pro+ continuous execution as a conditional maximum of 24 hours when sufficient compute units remain. The pricing page describes background execution after the browser closes, again subject to a positive compute-unit balance and a maximum duration. This is an upper-limit description, not a minimum-duration service promise. It does not establish that an actively connected notebook is exempt from all other resource constraints.

The two documents use different wording. The FAQ says resources are neither guaranteed nor unlimited, limits can fluctuate, and specific limits are not published. The pricing page separately says resources are not guaranteed and that limits and hardware availability must remain adjustable. Read together, they warn against planning as if every paid session will last 24 hours. They do not identify why a particular session ended, prove that every termination was intended, or establish that every possible termination complies with the service terms.

In issue #6101, AIBI0131 reports polling memory information, cgroup out-of-memory counters and kernel logs every 30 seconds. The reporter describes more than 40 GB of memory headroom, zero observed OOM kills, no observed GPU Xid errors and a heartbeat continuing until the final recorded tick. These are the reporter’s observations across several sessions, not diagnostics independently reproduced or inspected by this publication. The account’s remaining compute units are also user-reported.

Those observations make several simple explanations less compelling, but absence of a logged error is not proof that every memory, GPU, connectivity or platform fault was excluded. A heartbeat shows that a process ran; it does not expose the provider’s complete idle-classification logic or establish that the workload complied with every policy. In-VM logs also cannot reveal host scheduling, account decisions or a server-side termination reason. A WebSocket close code alone is a symptom rather than a diagnosis.

The reporter describes a single-session termination at about 2 hours 15 minutes of active work and other terminations between 3 hours 5 minutes and 3 hours 49 minutes of VM age while three notebooks ran in parallel. These are different configurations and different clocks; subtracting them would not measure one fixed termination threshold. The small, account-specific record cannot establish either a universal hidden cap or its absence.

Other issue participants report premature L4 or A100 termination, including a Colab Pro user. Their comments show that more than one person describes a similar symptom, but do not establish incidence, a shared root cause, a common subscription entitlement or a hardware-wide policy. Scheduler behavior, a runtime regression and infrastructure faults remain hypotheses to distinguish, not findings of this study.

On October 1, 2026, a commenter using the name spencersgoogle states that L4 runtimes are not pruned differently and asks whether the reporter uses the latest or a previous runtime version. That response is a useful lead for a version comparison. It is not independently verified telemetry, a completed support investigation or proof excluding differential treatment. The thread still does not provide this account’s server-side reason for termination.

The FAQ describes in-product feedback as a route for bug reports. The reporter says feedback was submitted. A useful escalation should preserve the issue reference, actual subscription tier, runtime version, accelerator, timestamps, compute-unit observations and the distinction between active-work time and VM age. Related issue numbers are investigation leads, not proof of a common fault. Public documentation’s failure to publish all limits does not explain why this particular support question remains unresolved.

For the next comparable run, confirm the actual plan and runtime version before treating a Pro or Pro+ anecdote as the same entitlement. Record checkpoint timestamps, the last successfully saved output, the termination timestamp and any support response. Compare runs under matched conditions where practical. A provider reason code or reproducible version-dependent difference would materially change the diagnosis; without either, paying for more units has no demonstrated ability to fix this failure.

The buying question is how much useful work survives a termination and how much operational control the workload requires. If saved state permits an inexpensive restart, the conditional runtime may remain acceptable; if most progress is repeatedly lost, test a better recovery design or evaluate a service with suitable resource controls and explicit commitments. The FAQ points to dedicated GCP Marketplace options and Colab Enterprise for guaranteed resources without Colab-enforced usage limits. That does not by itself promise an uninterruptible job, a contractual minimum runtime or a measured saving. Compare the actual terms, recovery burden and total workload cost before switching.