Log Viewer

A high-performance log viewer built on a Rust-side ring buffer. Free covers the normal single-pod workflow and deep history search; Pro adds multi-pod aggregation.

This page focuses on the log workflow itself: finding the right stream, searching quickly, and moving between single-pod inspection and workload-level debugging without losing context.

Overview

Krust streams container logs via the Kubernetes API and stores them in a Rust-side ring buffer capped at 100,000 lines. The buffer is lock-free for readers, so scrolling and searching never block incoming log lines. Full-text search across the entire buffer completes in under 15ms.

The practical value is not just speed. It is that search, scrolling, and filtering stay usable while logs continue arriving, which is where many simpler viewers break down.

When This Viewer Helps More Than kubectl logs

• When the error could be in one of several replicas and you do not know which pod yet.
• When you need to search repeatedly across a large active stream.
• When structured logs are present and raw JSON is slowing down human scanning.

Log Level Filtering

Krust automatically detects log levels from each line and displays color-coded badges:

• Error — Red badge, critical failures
• Warning — Yellow badge, potential issues
• Info — Blue badge, informational messages
• Debug — Gray badge, verbose debug output
• Trace — Dim badge, lowest-level tracing

Click any badge to filter the log view to only lines matching that level. Combine multiple levels to narrow down exactly what you need.

Search

Open the find bar with Cmd+F to search through logs. Both plain text and regex patterns are supported. Use the up/down arrows in the find bar to navigate between matches, with the current match highlighted in the scroll view.

This is best used as iterative narrowing: start with a service name or request ID, then switch to regex only when plain search is no longer precise enough.

Free covers both the visible working set and deep history search across the retained log buffer when the signal is no longer in the currently visible window.

Container Picker

For multi-container pods (sidecars, init containers, etc.), the container picker lets you select which container's logs to view. Switch between containers without losing your scroll position or search state in other tabs.

Multi-Pod Aggregation Pro

Stream logs from all pods in a Deployment, StatefulSet, or DaemonSet simultaneously. Each line is prefixed with the pod name so you can trace requests across replicas. Toggle between aggregated view (all pods) and single-pod view at any time.

This is the mode that matters most during rollout failures, partial replica crashes, and noisy incidents where the failing pod is not obvious at first glance.

Structured Log Parsing Free

Krust detects JSON and logfmt structured logs automatically:

• JSON compact mode — Collapses JSON log lines into a readable summary with field discovery
• Field toggles — Hide noisy fields and focus on the values that matter

Structured mode is not just cosmetic. It reduces the time spent visually parsing long JSON lines when the real question is which fields changed and which values are outliers.

Log Inspector Free

Inspector stays free. Click any log line to view parsed fields and raw payload in one place while you continue scanning the stream.

Export & Bookmarks Free

Export the current log buffer to a file for offline analysis or sharing. Bookmark important log lines to create a quick-navigation list — jump between bookmarks without scrolling through thousands of lines.

Recommended Usage Pattern

• Start with a single pod if the failing container is obvious.
• Switch to multi-pod aggregation when the failure is intermittent or replica-specific.
• Use bookmarks for the few lines that actually change your diagnosis, not for every error line.

Limits to Keep in Mind

• This is an operational log viewer, not a long-term log storage system.
• For retention, dashboards, and historical analytics, use your logging stack.
• For the exact implementation details behind the performance model, see Performance.