Hex dashboard cell failed: Python kernel error in notebook report fix
Fixes a Hex dashboard cell that fails with a Python kernel error by repairing the cell environment, inputs and code so the notebook report runs end to end. Use when one Python cell in a Hex project errors and blocks downstream cells. Not for a SQL cell failure, which runs on the warehouse rather than the kernel.
TL;DR
Run the project from the top and fix the failing cell in context. Hex Python cells share a kernel and pass dataframes between cells, so a kernel error often starts upstream, a missing package, a dataframe that changed shape, or memory pressure from an earlier cell. Restart the kernel, confirm the failing cell inputs, install the pinned package versions the project expects, and rerun the full sequence.
Hex dashboard cell failed: Python kernel error in notebook report fixUse this when
- A Hex project app or scheduled run fails and the log names a Python cell and a kernel error.
- The cell runs alone in a fresh session but fails in the full project sequence, or the reverse.
- A package was upgraded or an upstream SQL cell changed recently.
Not for this skill when
- The failing cell is a SQL cell erroring on the warehouse. Debug the SQL and warehouse connection instead.
- Every Hex project in the workspace fails at once. Check the Hex platform status before one project environment.
Steps
- Open the project in edit mode and run cells in order from the top, noting the first cell that errors. Verify: the first failing cell is identified rather than only the last reported one
- Read the full kernel traceback for that cell and note the exception type, such as a missing module, a missing column, or a memory error. Verify: the traceback names a concrete cause to act on
- Restart the kernel and rerun the sequence to clear state left by earlier partial runs. Verify: a clean run reaches the same failing cell or passes it
- Fix the named cause, installing the pinned package version in the project environment, correcting the column reference, or reducing the data an earlier cell loads. Verify: the previously failing cell completes after the fix
- Run the whole project end to end in app order and confirm every downstream cell and chart updates. Verify: a full run completes with no cell in an error state
- Publish the fixed version and, if the project is scheduled, confirm the next scheduled run succeeds. Verify: the run history shows a successful complete run
Why it happens
Notebook state is both the power and the hazard of the format. Cells that pass in isolation fail in sequence because the kernel carries real intermediate state, and published apps freeze one version of that sequence for viewers. Running the full order before publishing, and pinning the project package environment, are the two habits that keep the published behaviour equal to the tested behaviour.
A Hex project is an ordered notebook where SQL and Python cells feed each other and the published app renders the results. The Python kernel holds state across cells, so the cell that reports the error is frequently not the cell that caused it. Kernel restarts, package version drift in the project environment, and an upstream SQL cell returning a renamed column are the recurring triggers, and the app view hides most of that context behind one failed cell.
Field notes for Hex specifically. The project run history, the cell level logs, and the published app version together define what actually ran, and they often disagree with what the editor last showed, because publishing freezes a version. Always debug against the failing run version of the project rather than the current edit buffer, or you may fix a cell that was never the problem. Kernel state also means the run order in the app, not the order an author clicked through while exploring, is the sequence that must pass before publishing.
For Hex teams, the publishing checklist is the reliability tool. Run the project top to bottom in a fresh kernel, check the app view as a viewer rather than in edit mode, and only then publish or rely on the schedule. Projects that skip the fresh kernel run ship state dependent notebooks that fail for the scheduler at night. Pinning the project package environment and noting the pins in the project description closes the other common gap, where a library update quietly changes a cell result between two scheduled runs.
Variants and edge cases
Hex Python cell kernel error project run failed fix
The direct phrasing from the run log.
Hex notebook cell works alone fails in sequence state
The sequence variant where kernel state is the cause.
Hex app scheduled run Python cell missing package
The environment variant for package drift in the project.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstFPQ0hjbnAtdVqdWIxRYug