Why logdive exists.

Every backend engineer has hit the same wall. Something went wrong in production three hours ago, and now there's a 2 GB log file on a box somewhere, and you need to know which requests failed and what they had in common.

The options have always been a spectrum, and the spectrum has always been bad. On one end: grep piped into jq piped into awk, a shell incantation you rebuild from scratch every incident. On the other end: a full observability stack — Loki, Datadog, an Elastic cluster — with monthly bills, ingestion limits, and an entire infrastructure surface you don't want to maintain for a side project, a small team, or a single VPS.

logdive sits in that gap. It's the smallest tool that gives you indexes, time ranges, and a real query language, without asking you to provision anything. You install one binary, you point it at a log file, you query it later. That's the whole product.

Most existing systems start from "we need to ingest at scale" and work backwards into a usability story. logdive starts from the shell pipeline you'd write if you weren't tired, and works forwards — keeping the surface area roughly equivalent to a CLI you already know, but giving it persistence, structured fields, and time semantics.

If logdive does its job, you stop writing the same five-stage jq filter every time, and you stop paying someone to host the logs from your hobby Postgres instance. That's all it's trying to do.