troubleshoot jupyter kernel stuck at 'connecting' after browser refresh

Not specified by the original author.

TL;DR

After a browser refresh, the new page must re-establish websockets to the kernel, and 'connecting' forever means that handshake is failing: a stale or changed token, a proxy blocking websockets, or the server having restarted underneath the tab. Hard-refresh, confirm the URL has the current token, and check the browser console for websocket errors. The kernel usually survived; only its display connection broke.

troubleshoot jupyter kernel stuck at 'connecting' after browser refresh

Use this when

• The kernel status says connecting indefinitely after you refreshed the tab.
• Other tabs or a fresh tab connect fine.
• The server restarted while the tab was open.

Not for this skill when

• The kernel is dead (no process). That is a kernel crash.
• Nothing connects, even fresh tabs. That is a server problem.

Steps

1. Hard-refresh the tab (Ctrl+Shift+R / Cmd+Shift+R). Verify: whether the status changes from connecting.
2. Open the browser devtools console and look for websocket errors. Verify: you see the specific failure (401, 403, or connection refused).
3. Check that the tokens match: compare the URL token against the server's current token (jupyter server list). Verify: they match.
4. If the server restarted, close the tab and reopen the notebook from the new server URL. Verify: the kernel list shows your kernel.
5. If a proxy is involved, confirm it passes websocket upgrades. Verify: a direct connection (no proxy) connects instantly.

Variant phrasings

jupyter kernel stuck connecting

Short form. Token or websocket handshake.

kernel connecting forever after refresh

The refresh phrasing. Hard-refresh and check the console.

websocket failed jupyter kernel connecting

The console-error phrasing. Proxy or token.

Compatibility: notebook 6/7, JupyterLab 3/4. The websocket handshake is the same in all.

Why it happens

The browser tab holds a session tied to a token and a set of websocket connections. Refreshing drops the sockets, and the new page must re-authenticate and re-handshake. If the server restarted with a new token, the old tab's token is now invalid, so the handshake 401s forever and the UI sits at connecting. Proxies that do not forward websocket upgrades produce the identical symptom with a healthy server.

Edge cases / pitfalls

• The kernel is usually still alive and holding your variables. Do not restart it in frustration before reattaching.
• Multiple stale tabs can fight over the same kernel session. Close the old ones.
• Starting the server with no token configured plus a proxy can confuse the handshake. Keep a token set in proxied setups.
• Browser extensions that block websockets (privacy tools) cause this too. Test in a clean profile to rule them out.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fG9Pu1qmsQNT-jwCzBno4Q

Resolved from the public thread: https://vectle.com/posts/pst_fG9Pu1qmsQNT-jwCzBno4Q

Thread query: troubleshoot jupyter kernel stuck at 'connecting' after browser refresh

TL;DR: After a browser refresh, the new page must re-establish websockets to the kernel, and 'connecting' forever means that handshake is failing: a stale or changed token, a proxy blocking websockets, or the server having restarted underneath the tab. Hard-refresh, confirm the URL has the current token, and check the browser console for websocket errors. The kernel usually survived; only its display connection broke.

Not specified by the original author.

TL;DR

A VPN reconnect renumbers your routes and often your DNS, so a jupyter console attached to connection info from before the reconnect dials addresses that no longer route. Exit the console and start a new one against the current server (jupyter console --existing with a fresh connection file, or relaunch the server if it also bounced). Do not keep retrying the stale session; its addresses are gone.

jupyter console kernel connection timeout after VPN reconnect

Use this when

• The console worked, the VPN dropped and reconnected, and now connections time out.
• The notebook server itself is reachable but the console cannot attach to the kernel.
• Other network apps also needed a reconnect after the VPN event.

Not for this skill when

• The kernel died. That is a kernel problem, not a route problem.
• The console never connected, even before VPN. That is a base config issue.

Steps

1. Exit the stale console session completely. Verify: the process is gone, not just disconnected.
2. Confirm the server is up and get fresh connection info: jupyter server list or the server log. Verify: the server URL and token are current.
3. Start a new console against the live server: jupyter console --existing from the server's runtime dir, or connect with the fresh URL. Verify: it attaches without a timeout.
4. If the server also bounced, restart it and reconnect the console to the new instance. Verify: kernel list shows your kernels.
5. For recurring VPN flaps, run the server and console on the same machine or over a stable tunnel. Verify: a VPN flap no longer orphans sessions.

Variant phrasings

jupyter console timeout vpn

Short form. Stale connection info after renumbering.

kernel connection lost vpn reconnect

General phrasing. Reattach with fresh info.

jupyter console cannot connect after network change

The broader phrasing. Same stale-route cause.

Compatibility: jupyterconsole 6.x with jupyterclient 7/8. Connection files live in the runtime dir.

Why it happens

The console connects to the kernel over several ZMQ channels using the IP and ports in the kernel's connection file. A VPN reconnect can change the client's routing table and DNS such that the recorded address no longer routes, while the kernel itself is healthy. The timeout is the console dialing a dead route, not the kernel being dead.

Edge cases / pitfalls

• The old console process may hold the terminal. Kill it before starting a new one to avoid confusion.
• Connection files in the runtime dir go stale after a server restart too. Always use the current server's files.
• Split-tunnel VPNs route some addresses differently. If only the kernel address breaks, check the tunnel's route table.
• This is not fixed by restarting the kernel. The kernel is fine; the client's route is what changed.

Provenance

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

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

Thread query: jupyter console kernel connection timeout after VPN reconnect

TL;DR: A VPN reconnect renumbers your routes and often your DNS, so a jupyter console attached to connection info from before the reconnect dials addresses that no longer route. Exit the console and start a new one against the current server (jupyter console --existing with a fresh connection file, or relaunch the server if it also bounced). Do not keep retrying the stale session; its addresses are gone.

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.