Search

Everything you collect is queryable through the same interface — application and system logs, host metrics, and traces. Because every field was named at collection time, you filter and aggregate on real field names, not on substrings you hope are stable.

You don't write a query — you build one

There is no query language. An investigation is scoped to what you're looking at — a source, or a service, host or category you pick — and the query itself is a trail of chips you assemble in one bar: pick a field, an operator, a value. The operators are the obvious ones — =, ≠, >, <, ≥, ≤, contains, and exists / !exists for whether a field is present at all.

Nothing has to be memorised: the bar offers the fields actually present in what you're reading and the values they actually hold, so you discover the shape of a source by querying it. Every chip re-runs the query and lands in the URL, which makes an investigation shareable as a link — and removable one chip at a time when you've narrowed too far.

Grouping and metrics are part of the same flow

Group by any field and add metrics — count, sum, avg, min, max — from that same bar. They're commands in the trail, not a second syntax layered on top: a grouped, aggregated result is the same investigation with two more chips on it, and clearing them puts you back in the event stream.

Time is pinned to the trail

The time window is the first, permanent item on the trail, carried across every chip and every lens, so you never lose your place by changing what you're reading. Above the results, volume over time is drawn for the current filter — click a bar to narrow the window to it. Nothing else about the query changes; you're just looking closer.

One investigation, several lenses

The same scoped investigation reads through lenses. Events is the records themselves. Fields shows which fields are present in the current result set and how their values are distributed. Correlations surfaces the field values that are markedly more frequent in your filtered rows than in the window's baseline — the "what's different about these?" question — plus the traces those rows belong to. Traces is the spans behind them.

Switching lens doesn't rebuild anything: the filters and the window carry across, because the signal type is metadata on the data, not a mode you enter. It's the same surface whether you're reading logs, host metrics or traces, so you learn it once. One investigation reads one scope at a time — there's no single query spanning separate sources or signals, and we won't pretend there is.

The answer is in there

Nothing was sampled away or dropped to fit a budget, so search runs against the whole record, not a thinned-down sketch of it. Combined with the compression engine, that's the point of keeping everything: the question you didn't know to ask up front is still answerable after the fact.

How fast it is

Logs here are structured records, so the normal query is a structured-field filter — severity, service, host, a code — not a text grep. That's where it flies: on a 16.6-million-event corpus, equality filters over structured fields come back in 15–17 ms median server time. You don't tune indexes or decide what's queryable to get there; every field is already indexed.

Counting by a one-hour time window returns in about 138 ms. Broader tail/message text scans — the fallback, not the normal path — run longer, from a few hundred milliseconds into the low seconds; we're honest that those aren't the 15 ms case. (Server-side median over 30 runs, warm cache, single test machine.)

Where this is going: querying with an agent

Because every field is classified as it's ingested, Logpacer knows which ones carry personal data. The end goal we're building toward is letting you point the AI coding agent you already use at all of it — querying across logs, metrics and traces in natural language — while anything classified as personal data is held back and never leaves the EU. That interface is in active development. It isn't live yet, and we won't pretend it is.