When a kernel won't start, an init script fails, or a Spark job behaves unexpectedly, the kernel logs are usually where the answer lives. The kernel logs viewer is a built-in modal that streams those logs in your browser — no kubectl, no shell, no admin help required. Open it from a toolbar button next to the Spark UI button and you're looking at the live log stream for the kernel attached to this notebook.
Bootstrap tab and Spark tab
The viewer has two tabs and you'll spend most of your time in one or the other depending on what you're debugging.
- Bootstrap — the kernel pod's stdout. This is where the global, runtime, and notebook init scripts log their output, where dependency installs report success or failure, and where the kernel boot sequence shows up. If your kernel won't start, or the runtime toolbar shows "kernel is dead — bootstrap likely failed," this is where to look.
- Spark — the Spark driver and JVM logs. Spark errors, executor failures, missing JAR class errors, OOM stack traces, and SQL plan analysis output all land here.
In short: kernel won't start → Bootstrap. kernel started but Spark misbehaving → Spark.
Reading the logs
Three controls shape what you see:
- Severity coloring — ERROR is red, WARN is yellow, INFO is the default text color. Stack-trace continuation lines have no severity of their own; the viewer carries the severity of the parent line forward, so a 30-line Python traceback under a single ERROR stays red end-to-end.
- Tail size — pick how many lines to load: 500 / 1000 / 5000 / Full. Smaller is faster; larger gives you more history. Defaults to 500.
- Line wrap toggle — switch between wrapped (default — readable) and unwrapped (preserves the structure of long lines, e.g., wide JSON or long stack frames).
Searching and tailing
Type into the search box at the top of the modal and the view filters as you type. Lines that don't match dim out so the matching lines stand out. Clear the box to see everything again. Search is a substring match — no regex, no escaping needed.
Turn on Auto-refresh to keep the view live-tailing as new log lines arrive. The viewer fetches new content periodically and appends it to the bottom. Auto-refresh respects your scroll position: if you're at the bottom of the log, the view scrolls to keep new lines in sight; if you've scrolled up to read something older, the view stays put and a floating ↓ jump to newest pill appears in the corner. Click the pill to snap back to the bottom and resume tailing.
If you'd rather pull updates by hand, leave auto-refresh off and use the Refresh button when you want a new read.
Download and copy
Two actions to take the logs out of the modal:
- Download — save the current view as a .log file. Useful for attaching to a bug report or grepping locally.
- Copy — put the current view on your clipboard. Quickest way to paste a stack trace into a chat thread.
Both actions work on the filtered view — what you see is what you get. To capture the full unfiltered logs, clear the search box and bump the tail size up first.
Things to know
Two small caveats worth keeping in mind:
- Logs reset on kernel pod restart. The viewer reads from inside the running kernel pod. When the pod restarts — for any reason — its log files start fresh. Anything from a previous boot is gone. If you want to keep older logs, Download them before restarting.
- Each kernel has its own logs. Two notebooks with different kernels show different log streams; the viewer shows whatever is on the kernel attached to the notebook you opened it from.
Related sections
- Init Scripts & Dependencies. The layered global / runtime / notebook init script model. When the Bootstrap tab shows an error, this is the article that tells you which layer to edit.
- Init Script Logs & Troubleshooting. Full list of /logs/ file paths, SYNTASA_DEP_ERROR patterns, and the longer troubleshooting flow when the viewer doesn't have enough context.