# lazyjournal: a cross-source terminal log viewer

> lazyjournal brings journald, auditd, filesystem logs, Docker, Podman, Compose, Kubernetes, and remote log sources into one Go terminal interface. It suits operators who want interactive filtering and streaming without assembling a separate viewer for every logging backend.

**Lifailon/lazyjournal** — TUI for viewing logs from journald, auditd, file system, Docker and Podman containers, Compose stacks and Kubernetes pods with support for log highlighting and several filtering modes.

- Repository: https://github.com/Lifailon/lazyjournal
- Website: https://pkg.go.dev/github.com/Lifailon/lazyjournal
- Stars: 1,442 · Forks: 35
- Language: Go
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/lifailon-lazyjournal

## One lazyjournal session across local and container logs

lazyjournal addresses a practical fragmentation problem. On a Linux host, useful logs may not come from one service. Kernel and service output can reside in journald, security events can come from auditd, web servers can write files under `/var/log`, and container workloads can be split among Docker, Podman, Compose, and Kubernetes. Opening a different command-line tool for each source adds source selection and filtering work before an operator can inspect an event.

The project presents these sources through a terminal user interface built with `awesome-gocui`, a fork of `gocui`. Its intended audience is technical users who already work in a terminal, including system operators, developers troubleshooting containers, and administrators examining service output. The interface is especially relevant when an investigation crosses log boundaries, such as finding a Kubernetes pod message and then examining a related system service or filesystem log.

The README also covers platforms beyond a local Linux journal. It states that Windows Event Logs can be accessed through PowerShell and `wevtutil`, while Apple System Logs can be read in `asl` format. Remote systems can be reached over `ssh`, and rsyslog configuration can be used to search logs from multiple remote hosts. These statements describe supported source paths, not a guarantee that every source is available in every environment. Host permissions, installed utilities, service configuration, and runtime sockets still determine what appears in the interface.

lazyjournal also lists home-directory log files and file descriptors used by processes. Compressed rotated logs in `gz`, `xz`, and `bz2` formats are supported, as are `pcap` files and logs such as Apache or Nginx output. This breadth is useful for retrospective investigation, but it also means the tool is not limited to live service output. An operator can move between historical files, active journals, captures, and container records without first converting them into a common ingestion pipeline.

## Source selection, streaming, and lazyjournal filtering

The documented interaction model centers on selecting a log source and filtering lists of available journals, services, containers, stacks, or pods. For journald, lazyjournal lists system and user journals through `journalctl`, all services including disabled unit files, and available system boots for kernel output. For auditd, it lists rules and supports filtering by key and viewing output in `interpret` format. Container sources include individual Docker and Podman containers, Compose stacks, and Kubernetes pods.

New events from the selected journal can stream into the interface in a manner comparable to `tail`. Compose output can combine entries from containers in a stack and sort them by time. Docker logs can come from the filesystem or a stream, with built-in timestamps and stream filtering. Kubernetes access has an explicit prerequisite: the cluster connection must first be configured in `kubeconfig`. That condition matters because lazyjournal is a viewer, not a cluster configuration tool.

Four filtering modes are documented. Default mode performs a case-sensitive exact search. Fuzzy mode searches for all space-separated phrases anywhere in a line and is case-insensitive. Regex mode uses Go's built-in `regexp` package and is case-insensitive by default. Syntax errors cause the input field to be highlighted in red, which gives immediate interface feedback instead of silently accepting a malformed expression. Date mode filters journald entries through `since` and `until`; for Docker and Podman, date filtering is limited to streaming mode.

Date filtering can be combined with other modes. The README associates it with faster loading for large logs, and users can adjust the UTC offset through `-T/--timezone-filter` or the `timezoneFilter` configuration parameter, whose default is `+00:00`. Arrow keys alter the date range. These details make lazyjournal more than a static log browser, but they also define boundaries. Date-based narrowing for containers does not apply in the same way as journald filtering, and users who expect one identical query model across every source may need to account for backend-specific behavior.

## Built-in and external highlighting choices

Log formatting affects scanning long output, especially when a line contains timestamps, levels, service names, and event details. lazyjournal documents several output coloring modes. Its built-in highlighter is enabled by default and has no separate dependency. The README describes it as faster than other tools, but that performance claim is not supported by a benchmark included in the repository excerpt, so it should not be treated as an independent performance guarantee.

An alternative mode named `tailspin` delegates presentation to `tailspin`. Based on the documented design, this creates an explicit dependency and makes rendering behavior partly dependent on an external tool, while the default mode keeps more behavior inside lazyjournal. That is a meaningful trade-off for portable deployments: operators may prefer the dependency-free path, but teams that already standardize on `tailspin` may want consistent formatting with other workflows.

Color choices should also be considered separately from search. Regex and fuzzy filters decide which lines match, whereas highlighting changes how entries are displayed. A line can be selected by a filter without every component receiving a color, and the README does not enumerate custom color tokens. It also does not document color configuration beyond the presence of configuration support. Teams should therefore verify contrast and non-color cues on their terminal themes if highlighting is part of an operational workflow.

## Building lazyjournal from its Go module

The current README documents release binaries and installation commands for several platforms, including `brew install lazyjournal` and `conda install -c conda-forge lazyjournal`. It also documents command-line help via `lazyjournal -h`. Check the current instructions and release for your platform. The repository does expose a direct source workflow through its Makefile.

The module declares Go 1.25.0. For a source checkout with that toolchain available, the documented `run` target formats packages, runs `go vet`, resolves module dependencies, verifies them, builds the project to `/dev/null`, and finally executes `main.go`. The Makefile target is therefore more than a shorthand for `go run`; it performs checks before launching the interface.

Use the repository's development command from the repository root:

```bash
make run
```

The reader should see the `prep` checks complete before lazyjournal starts. Any formatting, vetting, dependency, or build problem interrupts this path before the TUI appears. That behavior is useful for a source checkout because it does not bypass the checks declared by the project.

For a narrower first launch without the Make target, the Makefile also contains this direct command:

```bash
go run main.go
```

This starts the application from the checked-out `main.go`, but the project metadata still requires Go 1.25.0. The README does not document the first screen, required terminal size, or initial key bindings, so an exact screenshot-level walkthrough would go beyond it. A real first use begins by confirming that at least one intended source appears in the source list, selecting it, entering a known text filter, and watching for matching entries. The expected visible result is a reduced log view, not a generated analysis report.

## Permissions and backend boundaries in remote deployments

lazyjournal's source coverage creates several failure points that are outside the TUI itself. Reading journald normally depends on access to system logs. auditd access depends on the audit configuration and the permissions of the running process. Filesystem discovery can expose broad categories of logs but does not make every file readable. Docker, Podman, and Kubernetes each require their own local access path, including runtime state or cluster configuration. A successful launch therefore does not prove that every source can be listed.

The project reduces dependency requirements for ordinary packaged use, since the README says one executable can run without settings or dependencies. Source builds and external highlighting are different cases. A Go checkout needs the declared Go toolchain and modules listed in `go.mod`. Selecting the `tailspin` highlighting mode also invokes an external project. Kubernetes pod logs additionally require `kubeconfig`, while remote access uses either rsyslog configuration or `ssh` according to the selected source.

lazyjournal can also launch its interface in a web browser when running in a Docker container. The README documents ttyd web mode with `TTYD`, `PORT` and optional username and password variables. It would be a mistake to infer that the web mode is safe by default merely because the binary is available as a container image. The deployment needs a documented network boundary and an explicit review of access to the host's logs and container runtimes.

For incident response, this is preferable to a viewer that only understands one format when evidence is spread across journald, auditd, containers, and files. It is less suitable when the requirement is unattended collection. The feature description centers on interactive viewing, filtering, and streaming; it does not claim durable indexing, alert rules, retention management, query history, or a documented multi-user web service.

## Release cadence, Go upgrades, and the MIT boundary

The repository is not archived, and its last push was on 2026-10-12. Recent listed releases include 0.8.6 on 2026-03-16, 0.8.5 on 2026-02-05, and 0.8.4 on 2026-01-24. Those records show recent development activity and a sequence of incremental releases, but they do not establish a fixed release schedule or guarantee compatibility between every minor release.

The declared Go version is 1.25.0, so source-based users need to account for Go toolchain upgrades as part of maintaining a local build. The direct dependencies are limited in `go.mod`, including `awesome-gocui`, `golang.org/x/text`, and `gopkg.in/yaml.v3`, with additional indirect modules. The Makefile includes dependency update and verification commands, but an organization should review `go.mod`, `go.sum`, and generated binaries before adopting an update.

The project is licensed under MIT. That permits use, modification, distribution, and sublicensing subject to the license conditions, including preservation of its copyright and license notice. The MIT label does not grant permissions over journal data, audit records, container output, or remote systems. Access to those sources still comes from the relevant operating-system and service permissions. No legal interpretation beyond the license text is needed for ordinary engineering review.

Compared with separate runtime-specific commands, it centralizes inspection in one interface. The trade-off is broader backend coupling: each source can fail or behave differently, and the application depends on host tools and permissions beyond the core Go binary.

## Conclusion

lazyjournal fits operators who inspect several local or remote log backends from one terminal and value interactive filtering over a fixed report format. It is a poor fit for teams that need a permanent web dashboard, automated alerting, or guaranteed coverage of every configured source without checking permissions and backend connectivity. Before adoption, verify the first target in this order: journald or filesystem permissions, then container runtime access, then `kubeconfig` connectivity, and finally the behavior of the required filtering and highlighting modes.

## FAQ

### What log sources can lazyjournal view?

lazyjournal documents support for journald, auditd, filesystem logs, Docker and Podman containers, Compose stacks, Kubernetes pods, remote hosts, Windows Event Logs, and Apple System Logs. Availability depends on the host, installed tools, and permissions.

### Does lazyjournal support regex and streaming log filters?

Yes. Regex mode uses Go's built-in `regexp` library, and the selected journal can stream new events like `tail`. Date filtering also supports `since` and `until` for journald, with source-specific limits for Docker and Podman streaming mode.

### How do I build and run lazyjournal from source?

The Makefile provides `make run`, which performs formatting, vetting, dependency, verification, and build checks before running `main.go`. The module declares Go 1.25.0, and the Makefile also contains `go run main.go` as a direct source command.

## Sources

- [License: MIT](https://github.com/Lifailon/lazyjournal/blob/main/LICENSE)
- [Lifailon/lazyjournal on GitHub](https://github.com/Lifailon/lazyjournal)
- [Project website](https://pkg.go.dev/github.com/Lifailon/lazyjournal)
- [README](https://github.com/Lifailon/lazyjournal/blob/main/README.md)
- [Releases](https://github.com/Lifailon/lazyjournal/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lifailon-lazyjournal