quarto render timed out executing a long-running notebook cell

TL;DR

Raise the execute timeout or enable caching so long cells can finish, and split truly long work out of the document. The default execution timeout kills cells that run longer than a few minutes; the fix is a larger budget, not a faster cell. Set execute timeout in the document YAML and use freeze or cache for expensive-but-stable cells.

quarto render timed out executing a long-running notebook cell

Use this when

• quarto render fails with an execution timeout on a specific long cell
• The same notebook runs fine interactively but fails under quarto render
• The timeout always hits the same expensive cell (model fit, large download)

Not for this skill when

• The cell raises an exception quickly - that is a code problem
• quarto cannot find the jupyter engine - that is item 112
• The kernel dies from memory pressure - that is a resource problem

Steps

1. Identify the slow cell: render with execution echo or run the notebook manually and time each cell. Expected: one cell dominates the runtime.

2. Raise the timeout in the document front matter: execute: timeout: 1800 (seconds) or set it per project in _quarto.yml. Expected: the YAML parses and quarto accepts the value.

3. Enable caching for expensive stable cells: execute: cache: true, so re-renders skip unchanged work. Expected: the second render reuses the cache and finishes fast.

4. Re-render. Expected: the long cell completes inside the new timeout and the document builds.

5. For cells that will always be slow, move the computation to a script that writes artifacts, and have the document read the artifacts. Expected: renders stay fast and the heavy work runs on its own schedule.

Tool compatibility

Quarto 1.4+ / 1.5+, Python 3.9+, jupyter_cache optional

Variant phrasings

quarto render timed out executing cell

Same fix applies: see the Steps section above.

quarto execute timeout long notebook

Same fix applies: see the Steps section above.

quarto render hangs on slow cell

Same fix applies: see the Steps section above.

Why it happens

Quarto executes documents through nbclient, which enforces a per-cell timeout (default 600 seconds in many setups). Interactive use has no such guard, so a cell that takes 20 minutes works in the notebook but dies under render. The timeout exists to catch hung renders in CI, so the right fix is a deliberate larger budget for known-slow cells plus caching, not disabling timeouts globally. Cells slower than the timeout on every render are a design smell: the document should consume precomputed artifacts instead of redoing the work.

Edge cases / pitfalls

• Cache invalidation on code change still re-runs the slow cell; cache helps re-renders, not first builds.
• A timeout of -1 (no timeout) in CI can hang a pipeline forever; prefer a generous finite value.
• Memory growth across cached cells can still OOM the render; watch peak RSS on big documents.

Provenance

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

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

Thread query: quarto render timed out executing a long-running notebook cell

TL;DR: Raise the execute timeout or enable caching so long cells can finish, and split truly long work out of the document. The default execution timeout kills cells that run longer than a few minutes; the fix is a larger budget, not a faster cell. Set execute timeout in the document YAML and use freeze or cache for expensive-but-stable cells.