humanlog makes logs readable, then keeps them

One binary, two jobs

The description is compact and covers both halves. It reads logs from standard input and prints them back to standard output, but prettier, and it is also a localhost observability platform supporting logs and distributed traces. The first use is a filter. If you emit logs in JSON or in logfmt, you get pretty output when those entries are encountered by humanlog, and lines it does not recognise are left unchanged, which is the behaviour that makes it safe to put in a pipeline over a mixed log file. The second use is the platform, where the same parsing work feeds a local database and a web interface, so the logs and traces your machine produced during a debugging session can be explored afterwards rather than scrolled through. Both halves are Go, and the repository layout shows it, with the handler files, the scanner, the time parsing and the optimisation pass all at the top level.

Installing is a shell script

The install command in the README is a curl pipe to bash:

curl -sSL "https://humanlog.io/install.sh" | bash

and the documentation is the place to read before running it, with the installation page linked as how to install. The project is also published as official releases at humanlog.io, and the repository has a goreleaser configuration for the community build. The distinction matters more here than in most projects, and it is spelled out in the licence section. The core CLI is Apache 2 licensed, meaning everything in the repository, while the official releases include proprietary code that is inserted at build time, which is the query engine. So there are two builds, one you can compile from this repository and one you can download, and they are not the same program.

The filter is the part you can rely on

Using it as a filter is one line:

$ humanlog < /var/log/logfile.log

The behaviour that matters is stated in the README, that if you emit logs in JSON or in logfmt you will enjoy pretty logs when those entries are encountered, and that unrecognized lines are left unchanged. That second property is the one that makes the tool usable in anger. A log file on a real machine contains your application's structured output mixed with kernel messages, library warnings and stack traces, and a tool that refused to run on the unrecognised lines would be useless, so humanlog passes them through. The source tree shows how that is arranged, with a separate handler per format, one for JSON, one for logfmt and one for Zap's development output, plus a scanner that reads the input, a time parser for timestamps, and an optimisation pass.

Everything parsed is stored locally

When the logs are parsed, they are persisted in a local database, and you can then query and explore them through the web UI. The same is true of traces, which are ingested and persisted in a local database when sent over OpenTelemetry or OTLP. The consequence is that the tool is not just a pretty printer with an optional backend, it is a local store, and the storage is on your machine, which is the privacy story the project leads with. The trade is the usual one for a local database, since the volume of logs a busy development machine produces will eventually fill it, and the tool gives you no instruction in the README about retention.

Querying, and where the open source ends

With the query engine turned on, which the README says is the default on new installations, you can query the logs and traces you ingested, and the query language is pipe-like:

$ humanlog query "spans | where duration > 100ms"

That syntax is a span pipeline with a filter on the duration field, and the documentation has a page on how to query. Here is the catch, and the README is direct about it. The core CLI is Apache 2 licensed, everything in the repository, and the official releases include proprietary code that is inserted at build time, which is the query engine. So the query capability that the README demonstrates is not in the open repository, and the build you make from this tree is the filter, the scanner and the handlers. That is a reasonable business model for a project whose commercial product is the local observability platform, and it is also the first thing to check before you plan to depend on the query language, because the language you read about in the docs is implemented in code you do not have.

Ingesting traces over OTLP

Traces are ingested via OpenTelemetry and OTLP, and the README says that using the OpenTelemetry client of your language will work out of the box with the default configuration, and otherwise you point your exporter at localhost:4317 or localhost:4318, which are the default values. The table of other valid values for OTEL_EXPORTER_OTLP_ENDPOINT is the practical part, because the default only works when the exporter and the collector are on the same host. The table lists the default for the same host over OTLP and HTTP at port 4317 and over OTLP and gRPC at port 4318, and then, for Docker, Orbstack and kind, the same two ports but reached through host.docker.internal, with 4317 for HTTP and 4318 for gRPC. That is the container networking detail that otherwise costs an afternoon, and it is right there in the README.

The repository and the release state

The tree is a Go project with a vendor directory and a goreleaser configuration, and the layout is readable. The command implementations live under cmd/, the reusable pieces under internal/ and pkg/, and the root holds handler.go, json_handler.go, logfmt_handler.go, zap_development_handler.go, scanner.go, time_parse.go, optimize.go and docker_compose_handler.go, with the matching test files next to them, plus an end-to-end test and a benchmark test at the top level. The dependency list explains the feature set, with the logfmt and kr/logfmt parsers, the OpenTelemetry SDK and OTLP protocol packages, gRPC and protobuf, urfave/cli for the command line, the charmbracelet lipgloss and log packages for the pretty output, the 99designs keyring for credential storage, connectrpc for the RPC layer, and a couple of unusual ones, a flatjson library and an rgbterm colour library, which are the kind of dependency that tells you the pretty printer is the point of the project. The release history is v0.7.8 from 2024-10-25, v0.7.7 and v0.7.6 both from 2024-10-23, the last push was on 2026-04-24, the repository is not archived, the licence for the code in the tree is Apache 2, and the homepage is humanlog.io.

Editorial conclusion

humanlog fits a developer who wants readable logs on a machine with no log infrastructure, and the filter half is a good enough tool on its own, since it needs nothing but a pipe. It does not fit a team that needs a self hosted query engine they can build and run from source, because the query engine that ships in the official releases is proprietary code inserted at build time, and the community repository only carries the Apache 2 licensed CLI. It does not fit a production setup, since the storage is a local database on your own machine. Before you adopt it, read the licence section, because the split between the open CLI and the closed query engine decides whether the project is usable for your case, and note the release state, where v0.7.8 is from 2024-10-25 while the last commit was on 2026-04-24.

Frequently asked questions

Official sources

1. humanlogio/humanlog on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases