Skip to main content
Open a node, then select the Logs tab to read the output of the node’s underlying processes. The panel is titled Live logs and refreshes automatically every few seconds; a status dot next to the title shows connecting, connected, or error. Use this for quick, in-browser triage. For long-term retention, ship logs to your own store — see Keep logs longer.

​
Pick a process

A node can run more than one process. Three chains run more than one — Ethereum (execution + consensus), Igra (kaspad + execution), and Monad (three roles). Bitcoin, BSC, HyperLiquid, Sui, and Tron run a single process. When a node has more than one process, a Source selector appears in the panel header (its entries read Source: <role>). Pick the process you want to read:
  • Ethereum — el for the execution-layer client (Geth), cl for the consensus-layer client (Lighthouse).
  • Igra — el (igra-reth) and kaspad.
  • Monad — execution, consensus, and rpc.
  • Single-process chains (Bitcoin, BSC, HyperLiquid, Sui, Tron) — one source. The selector is hidden because there’s nothing to switch between.
Switching the source reloads the panel with that process’s lines. Logs from different processes are not interleaved. You can jump straight here from the node’s Overview tab: each component panel has a View logs button that opens this panel with the Source already set to that component. It reads Logs unavailable until the executor has reported the node. Three controls in the header narrow what you see:
  • Level — pick one or more of Trace, Debug, Info, Warn, Error, and Fatal; with none picked, every level is shown. The filter returns exactly the lines whose level badge shows a level you picked. Each client writes its own level words; the platform normalizes them so Geth’s WARN, Lighthouse’s WARN, and Bitcoin’s warning all match Warn, and a line’s badge takes the higher of the record’s own severity and any severity word in the line.
  • History — how many recent lines to load: Last 100, Last 200 (default), Last 500, or Last 1000 lines. A larger value gives more context up front. Use the default for routine checks; raise it for incident triage.
  • Search logs — a free-text box that filters to lines containing your term (timestamp, level, source, and message are all searched).
As soon as you apply a level or a search term, the panel searches the last 48 hours of history for this node in Loki — not just the lines already loaded — and the toolbar names that window. So a match from before the current buffer, or from before a recent restart, still shows up. Every matching page is loaded before the result settles. Clear the filters and the panel goes back to its recent-lines view, bounded by the History setting.

​
Follow, wrap, and read

  • Follow (on by default) auto-scrolls to the newest line as the panel refreshes. Scroll up and it turns off so the view stays put; a Jump to latest button appears to re-pin and turn it back on. Changing the level, a search term, or the source turns Follow back on and opens the new results at the newest match.
  • Wrap (on by default) wraps long lines instead of scrolling them horizontally. Turn it off to read wide, structured output without rewrapping.
Control and color codes that clients emit (ANSI escape sequences) are stripped before logs are stored and shown, so lines render as clean, readable text rather than raw escape bytes.

​
Copy and download

  • Copy logs puts the currently visible lines on your clipboard.
  • Download saves them to a .txt file named after the node and process.
Both act on what’s filtered into view, so narrow with the level filter and search first to export just the lines you care about.

​
Retention

In-UI logs cover roughly the last 24 hours of activity and are meant for live troubleshooting, not archival. To keep logs longer, forward them from your own infrastructure.

​
Keep logs longer

The Connect logger button (header) opens the External loggers dialog, which generates a Grafana Alloy configuration that ships this node’s logs to your Loki or any Loki-compatible collector. The snippet is pre-filled with this node’s identifiers (node id, chain, network) and tailored to the node’s backend. To stand up the collector that the snippet feeds, follow the recipe for your backend — provision on bare metal or provision on Kubernetes.
  • Node monitoring — sync progress, peers, and per-process metrics.
  • Events feed — lifecycle transitions and errors as structured events.